Currently i am working on a project and i am using django-kronos for scheduling so, when user schedule a task i am running a script and end of the script i need to run
python manage.py installtasks
this is help to insert the tasks in crontab.
script is working fine when i execute in terminal but when i integrate it with my django app, it's throwing an error
IOError: Read crontab nobody: You (nobody) are not allowed to use this program (/usr/bin/crontab)
I really curious to know about which cause this problem?
or did i miss anything?
Setting setuid flag on the script (chmod u+s) will make the script run as the script file's owner UID if it's run as a separate process. You then need to watch who is allowed to execute it and/or do some authentication or check of the running user as with anyone else executing it, it'll be the same.
This is pretty much a workaround and is not advisable if some better facility is available in the app.
From what I can see, django-kronos logic is supposed to be run from manage.py rather than web code proper.
Related
No, I'm not talking about runserver listening for requests.
Whenever i run makemigrations, migrate or scripts i wrote using django-extensions command runscript, I need to stop the execution of the program before typing in another. This was not the case before restarting my PC this morning.
I'm building a small QR code ticketing app and it was working up until this morning. I fixed a bug regarding opencv since and the app is functional again, but this command line issue is bothering me. I'm going to have to make the /admin and scripts available to a few of my colleagues tomorrow and i'm afraid we won't know when the script running is actually done since it doesn't prompt or allow another command. Having a script executed terminated early because of this would be catastrophic.
whenever i run a command, the blank line not accepting input appears
There's way too much possible reasons why this could've happened; and it's impossible for anyone else to reproduce your scenario just based on what you described. This isn't a widespread issue, so it must something particular to do with your setup.
Run a debugger, like pudb or pdb to find out where the script is stuck on.
Or add a try-except block to catch KeyboardInterrupt to your manage.py and use traceback library to narrow down where it's stuck.
My friends and I have written a simple telegram bot in python. The script is run on a remote shared host. The problem is that for some reason the script stops from time to time, and we want to have some sort of a mechanism to check whether it is running or not and restart it if necessary.
However, we don't have access to ssh, we can't run bash scripts and I couldn't find a way to install supervisord. Is there a way to achieve the same result by using a different method?
P.S. I would appreciate it if you gave detailed a explanation as I'm a newbie hobbyist. However, I have no problem with researching and learning new things.
You can have a small supervisor Python script whose only purpose is to start (and restart) your main application Python script. When your application crashes the supervisor takes care and restarts it.
I have a small problem running a python script as a specific user account in my CentOS 6 box.
My cron.d/cronfile looks like this:
5 17 * * * reports /usr/local/bin/report.py > /var/log/report.log 2>&1
The account reports exists and all the files that are to be accessed by that script are chowned and chgrped to reports. The python script is chmod a+r. The python script starts with a #!/usr/bin/env python.
But this is not the problem. The problem is that I see nothing in the logfile. The python script doesn't even start to run! Any ideas why this might be?
If I change the user to root instead of reports in the cronfile, it runs fine. However I cannot run it as root in production servers.
If you have any questions please ask :)
/e:
If I do sudo -u reports python report.py it works fine.
Cron jobs run with the permissions of the user that the cron job was setup under.
I.E. Whatever is in the cron table of the reports user, will be run as the reports user.
If you're having to so sudo to get the script to run when logged in as reports, then the script likely won't run as a cron job either. Can you run this script when logged in as reports without sudo? If not, then the cron job can't either. Make sense?
Check your logs - are you getting permissions errors?
There are a myriad of reasons why your script would need certain privs, but an easy way to fix this is to set the cron job up under root instead of reports. The longer way is to see what exactly is requiring elevated permissions and fix that. Is it file permissions? A protected command? Maybe adding reports to certain groups would allow you to run it under reports instead of root.
*be ULTRA careful if/when you setup cron jobs as root
I have tried using both subprocess() and os.system()
import os
def whatever(request):
open file
code write to file
close file
os.system(command theFileIwroteto argument)
Now the code is fine. I have opened python and literally copied and pasted the exact command in and it works fine.
python:
import os
os.system(command theFileIwroteto argument)
Why would it work using the python shell but refuse to execute from the django views file?
You should look at the error log in order to make a proper diagnostic.
Without more information, I can think of two reasons:
The Apache mod_wsgi restricts access to stdout, and the command you are running outputs to stdout. If you are using mod_wsgi, look for errors like IOError: sys.stdout access restricted by mod_wsgi in the logs;
You are testing your command while logged in as your user or root, but the webserver is running as other user with less privileges (like www-data in Ubuntu). Find out under what user the webserver is running, su to the same user and try the same commands. Any error will hint you about the permissions lacking.
It is almost always a bad idea to run a shell from a Django view, specially if the command take a few seconds to run. It has bad scalability, makes easier for someone to DDoS your site and makes responses slow. The proper way to do it is to place the job on a queue and have one or more background processes consuming this queue. Take a look at celery, its popular for this kind of task.
I am using Debian and I have a python script that I would like to run during rc.local so that it will run on boot. I already have it working with a test file that is meant to run and terminate.
The problem is that this file should eventually run indefinitely using Scheduler. It's job is to do serial reads, a small amount of processing on those reads, and inserts into a MySQL database. However, I am nervous about then not being able to cancel the script to get to my login prompt if changes need to be made since I was unable to terminate the test script early using Ctrl+C (^C).
My hope is that there is some command that I am just missing that will accomplish this. Is there another key command that I'm missing that will terminate the python script and end rc.local?
Thanks.
EDIT: Another possible solution that would help me here is if there is a way to start a python script in the background during boot. So it would start the script and then allow login while continuing to run the script in the background.
I'm starting to think this isn't something that's possible to accomplish so other suggestions to accomplish something similar to what I'm trying to do would be helpful as well.
Thanks again.
Seems like it was just a dumb mistake on my part.
I realized the whole point of this was to allow the python script to run as a background process during boot so I added the " &" to the end of the script call like you would when running it from the shell and viola I can get to my password prompt by pressing "Enter".
I wanted to put this answer here just in case this would be something horribly wrong to do, but it accomplishes what I was looking for.
Making scripts run at boot time with Debian
Put your script in /etc/init.d/. So, if your script is in a file called my_script, it should be located at /etc/init.d/my_script.
Run update-rc.d my_script defaults as root.
Don't forget to make your script executable and include the shebang. That means the first line of the script should be #!/usr/bin/python.