I want to have a script running in screen at startup.
This doesn't work:
@reboot pi screen -d -m /home/pi/db_update.py
however running this manually as user pi works:
screen -d -m /home/pi/db_update.py
Any idea on what I am missing?
Instead of adding
@reboot pi ... to
/etc/crontab you should run
crontab -e as user
pi and add:
@reboot /usr/bin/screen -d -m /home/pi/db_update.py
Make sure to use the full path to screen (just to be sure, it works without it), and that the /home/pi is not on an encrypted filesystem (been there, done that). The command cannot depend on anything that might only be accessible after either the
cron daemon has started, or the user is logged in.
You might want to add something to
db_update.py (writing to a file in
/var/tmp to see that it actually runs, or put a time.sleep(600) at the end of the python program to allow enough time to login and connect.
Tested on Lubuntu 13.04, python 2.7.4 with the following entry:
@reboot screen -d -m /home/anthon/countdown.py
#!/usr/bin/env python import time for x in range(600,0,-1): print x time.sleep(1)
chmod 755 countdown.py)
While this may be a workaround, I have overcome this issue by running a shell script which invokes my screen session.
[dude@server ~]$ crontab -l | grep sh @reboot /home/dude/.autoscreen/start.sh [dude@server ~]$ cat /home/dude/.autoscreen/start.sh #!/bin/bash cd ~ screen -S myname -d -m custom_script
I had a similar but slightly different use scenario for needing screen attached to something on startup. I have two headless servers, one of which has serial-only output. I have this attached to the other headless server via serial cable and I needed to use screen to interact via the serial connection. I also need to make sure I've captured any output generated while not viewing the serial session.
I have this in root's crontab
@reboot /usr/bin/screen -d -m -c .screenrc -L /dev/ttyS0
The server reboots at a set time of day if security updates have been applied. I want specifically named log files so I can review them if need be. My
.screenrc file has this entry in it
so when the next screen session is started, the log file is at
There are a few simple ways to figure what is going on with that screen started upon boot:
does it even start? after reboot,
grep CRON /var/log/syslog should return a
CMD line for it after the line saying
(CRON) INFO (Running @reboot jobs)
if it starts, but the screen is gone by the time you look, then the command within exited - there's several ways to debug this, for example:
screen ... -- sh -c "your command; exec sh"
screen ... -- script -f yourcommand.boot.log -c "your command"and then examine the log file
In my case, it was a script that tried to connect to the local PostgreSQL database, which wasn't done booting, and it croaked with a
FATAL error message. That is, everything was fine with
screen as such, but the combination simply ran too soon in the machine boot-up sequence.
Also, I should mention that you don't have to necessarily switch from global crontab file (
/etc/crontab) to the user file, there's a middle ground in creating e.g.
/etc/cron/local-pi-whathaveyou with your command. That way it's obvious to anyone who examines
/etc, but you keep your unprivileged user.