Pretty new to all this so I apologize if I butcher my explanation. I am using python scripts on a server at work to pull data from our Oracle database. Problem is whenever I execute the script I get this error:
Traceback (most recent call last):
File "update_52w_forecast_from_oracle.py", line 3, in
import cx_Oracle
ImportError: libnnz11.so: cannot open shared object file: No such file or direct ory
But if I use:
export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
Before executing the script it runs fine but only for that session. If I log back in again I have to re-set the path. Anything I can do to make this permanent? I'm trying to use Cron as well to automate the script once a week. It was suppose to automate early Monday morning but it didn't run.
EDIT: Just had to add the path to my .bashrc file in the root directory.
Well, that was pretty simple. I just had to add it to the .bashrc file in my root directory.
Related
I made a python script which should start when I start my PC in order to do that I created a simple .bat file like this. But now I have a problem because why ever windows isn't able to open the database connection on startup. I tried it like this:
conn = sqlite3.connect('DB\Todos.db')
When I execute the baatch file normaly everything works but when windows starts it on startup this error comes up:
Traceback (most recent call last):
File "Path to my file", line 41, in <module>
conn = sqlite3.connect('DB\Todos.db')
sqlite3.OperationalError: unable to open database file
Of course where "Path to my file" is the normal path.
Thanks for your help
Of course this show that the system cannot find the specified file, this are the reason to they can't open the database file. If your program is in DB folder, you can just use
conn = sqlite3.connect('Todos.db') instead. And, the most recommended if is for personal purposes, is that you use the entire path, like conn = sqlite3.connect('X:\MyDB\SQLite\Todos.db'). The output error sqlite3.OperationalError: unable to open database file begins, normally, with these errors below:
System cannot find the file.
System cannot open the file.
System doesn't have the permission to the file (or you don't have).
System doesn't have READ permissions.
If cannot open find the file, move your script or your directory to the place that the file is. It's economize code, is much better than insert the full path, because if you have making the program to someone, is harder to say where the program is, and he/she will, probably, change the code, etc. But if everything is on a same folder, is a lot easy.
If cannot open the file, probably is corrupted; the program cannot read this ext of file or is not a program that he recognize. Or you don't pay the program.
If don't have permission to the file, you need to start the program as ADMINISTRATOR, if it doesn't work, search in the internet how to give permissions to an .(yourext).
For least, READ permissions is right on the file. Some files has an attrib, the "-r", the Read-only file attribute, remove it with an PROMPT (CMD) with admin rights, being in the folder of the file and typing attrib -r -s -h yourfile.ext, it removes the read-only, system and hidden file attributes.
If everything doesn't work, the file is corrupted. Sorry.
I was using the cluster manager slurm and I was running a submission script with sbatch (with a python interpeter). The sbatch submission imported one of my modules called main_nn.py. The module is located in the same place as my submission directory, however, python fails to find it even though the file exists. I am having a hard time figuring it out why this is happening. My python file looks as follow:
#!/usr/bin/env python
#SBATCH --job-name=Python
print('hi')
import main_nn
however the output of my slurm dump file is:
hi
Traceback (most recent call last):
File "/home/slurm/slurmd/job3223398/slurm_script", line6, in <module>
import main_nn
ImportError: No module named main_nn
I tried checking if the module main_nn was in the current directory and it was there indeed. Thus, the first thing that seemed suspicious to me was that the error in the slurm file said the location of my script was at "/home/slurm/slurmd/job3223398/slurm_script" rather than at path_to_project. Thus I went ahead an added the line
os.system('pwd')
to see where my script was executing from and to my surprise it was executing at path_to_project rather than at "/home/slurm/slurmd/job3223398/slurm_script" which must mean that sbatch is doing something funky to executed a script at one location but make it think its at another. If this is the case how am I suppose to do an import in python where the module is in the same location as in my submission script? Am I forced to put it in a package and trick python to think its in a package/library?
As Slurm copies the submission script to a specific location on the compute node to run it, your Python script will not find the modules that are in the submission directory.
But Slurm correctly sets the current working directory so you can explicitly add it to the python path with something like:
sys.path.append(os.getcwd())
near the beginning of your script.
Please consider the following problem:
I have a Python script that runs on a linux machine (Raspberry pi 3, running Rasbian Jessie) on boot.
This script has been added to sudo crontab -e
The script itself starts with no problem but is unable to load in a certain file that is in the same directory as the script (Desktop), I have any print statements/issues going into a log file. Which reads as follows:
Traceback (most recent call last):
File "/home/pi/Desktop/mainServ.py", line 18, in <module>
mouth_detector = dlib.simple_object_detector(mouth_detector_path)
RuntimeError: Unable to open mouthDetector.svm
I assume this is because the script has no access to a filesystem, or perhaps LXDE/Desktop at boot time? I could very well be wrong on this.
Any solutions to this problem will be greatly appreciated.
Whenever you execute a script via crontab be ready for environment variables to be different. In this case you can simply use the whole path in the file you are trying to reference.
To see what the current environment variables are from within Python, use:
import os
os.environ
You may find there are other differences between the crontab environment and whatever interpreter environment you are using for testing.
I have an issue with running python scripts on one server running RH Linux with Python 2.6.6. When I run any script and it produces an exception, the script hangs until I press CTRL-C and then it prints the traceback information. It happens when I run the script from the command-line without calling python directly, making use of the shebang on the first line of the script. If I execute the script by calling python , I don't have the same hanging issue. I've searched and seen similar issues, but they were related to specific libraries where this happens with all python scripts. I've tried a different servers with the same script and didn't have the issue. I have included a simple script that I have been testing with. It tries to open a non-existent file.
#!/usr/bin/env python
tempfile = open('noexists.txt','r')
When I execute the code as "test.py" on the command-line, I get the following response:
~/bin$> test.py
^CTraceback (most recent call last):
File "/export/home/jwd3/bin/test.py", line 2, in <module>
tempfile = open('noexists.txt','r')
IOError: [Errno 2] No such file or directory: 'noexists.txt'
If I execute it as "python test.py" then I get the following response:
~/bin$> python test.py
Traceback (most recent call last):
File "test.py", line 2, in <module>
tempfile = open('noexists.txt','r')
IOError: [Errno 2] No such file or directory: 'noexists.txt'
The difference is difficult to tell here, but it is very evident when executing. Look at the first sample output and notice the "^C" before the Traceback. Until I hit CTRL-C, the script was just hanging. The second sample output returns the traceback of the exception imediately without hanging.
I've tried moving the script to a new location, changing the shebang from #!/usr/bin/python to #!/usr/bin/env python and different scripts. In all cases they behave the same. Any help would be greatly appreciated. I do not want to call all python scripts using "python " format.
Thanks to the help from the suggestions above, I was able to find the solution to the issue. After running strace, I found the code was hanging on a socket connection. Searching for the same socket connection info, I found another issue already posted on Stack Overflow that was similar. I then found a second issue that was also very similar. Both issues had the same suggestion. Apparently the Python script was conflicting with a service called abrtd. The suggestion was to restart this service (abrtd). After restarting it, the issue with the Python script hanging was resolved.
Okay I am newer to python and have been researching this problem but I can't find anything like it so I am not sure what is going on.
I am creating a program that involves sage and it has a message cue. We have this set up on a development machine, so I know it works but I was wanting to set it up on my own computer so I could get a better understanding of how it all works and make it easier to develop for myself.
To start up sage, we run a script that calls sages main binary file and passes it an executable .py file. (./sage/sage ./sage_server.py) This creates an error in the sage_server.py file:
Traceback (most recent call last):
File "./sage_server.py", line 23, in <module>
from carrot.messaging import Publisher
ImportError: No module named carrot.messaging
But whenever I run that file just in the terminal (./sage_server) the import works fine and isn't until line 27 that there is an error when it tries to import something from sage.
Does anyone know what would cause the error when it is being called by something else? I am very lost as to what would be causing this.
Sage has its own python, separate from the system libraries. This "carrot" module, whatever it is, must be installed in whatever python ./sage_server.py uses, but not in Sage.
You should be able to use either
[your-sage] -sh
to start up a Sage shell and use easy_install, or you could get whatever carroty package you're using, find its setup.py file, and then run
[your-sage] -python setup.py install
where obviously your-sage is the path to your sage.
Things get a little trickier if the install process isn't setup.py-based.