6

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?

user
  • 28,901
Jrc
  • 63

4 Answers4

9

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

and the countdown.py:

#!/usr/bin/env python
import time
for x in range(600,0,-1):
    print x
    time.sleep(1)

(and chmod 755 countdown.py)

Anthon
  • 79,293
  • I'll try that out in a few minutes! – Jrc Jun 03 '13 at 12:25
  • Still its not running ... There is no error message or anything in syslog, so im not sure what could be wrong. – Jrc Jun 03 '13 at 12:35
  • I ran a screen from my crontab using 28 15 * * * screen -d -m find / that does work, will try to run on reboot as well. Stupid question: are you sure cron is running and can find the screen binary? – Anthon Jun 03 '13 at 13:32
  • 1
    its not throwing any error - in syslog I can see the cron calling the script as user pi on startup – Jrc Jun 03 '13 at 14:45
  • Jun 3 14:28:37 raspberrypi /USR/SBIN/CRON[1987]: (pi) CMD (screen -d -m /home/pi/dbpdate.py) Spotted a Typo! :) Ill try again right now – Jrc Jun 03 '13 at 14:47
  • Finally got it to work (first used an encrypted home dir on the VM that I was testing on). The difference was in specifying the full path to /usr/bin/screen. I will update the answer. – Anthon Jun 03 '13 at 14:51
  • I have /usr/bin in my path - so it should work without it. However I added it like you suggest but its still not working: Jun 3 16:55:30 raspberrypi /USR/SBIN/CRON[1969]: (pi) CMD (/usr/bin/screen -d -m /home/pi/db_update.py) – Jrc Jun 03 '13 at 14:58
  • Are you sure it is not db_update.py quitting because it depends on something? I included my test program, maybe you can try that. – Anthon Jun 03 '13 at 15:04
  • Ill test it in a bit - need to do some work then ill be back here tonight - thanks for the continuous help! – Jrc Jun 03 '13 at 15:45
  • Had not much time because of work - still had no success in running the screen session on startup, even with the script workaround. I'll keep trying - its probably something rather stupid I'm not seeing.. – Jrc Jun 06 '13 at 20:41
  • I just redid everything - I probably had some access rights not set properly - now it works! Thanks for your help! :) – Jrc Jun 06 '13 at 20:46
1

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

logfile "/root/.screen_%H_%Y%m%d_%c.txt"

so when the next screen session is started, the log file is at /home/root/.screen_$HOSTNAME_$YYYYMMDD_$h:$mm.txt.

user208145
  • 2,485
0

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:

    • run a shell afterwards so it continues running and you can examine the output, as explained at e.g. https://unix.stackexchange.com/a/47279/103306 - screen ... -- sh -c "your command; exec sh"
    • run the command within script(1), e.g. 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 cron and 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.

Josip Rodin
  • 1,138
0

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
dougBTV
  • 2,532