3

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?

4

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)

  • I'll try that out in a few minutes! – Jrc Jun 3 '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 3 '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 3 '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 3 '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 3 '13 at 14:47
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
  • Any ideas why doing this makes a difference (besides changing the cwd)? – Danny Tuppeny Jul 16 '18 at 17:21
0

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.