Launch code upon startup for RPi SBCs

[sgbaird]

@gursi26 @linx5o @Jonathan-Woo this applies to you. Ideally, we would have the RPis start running the device code by default on startup. @kenzo-aspuru-takata used crontab for the microscope I think. Out of five options mentioned here, crontab seems like the best. The OS doesn't load if an error is thrown in etc/rc.local. .bashrc runs every time a new terminal is opened. etc/init.d seems to run both at shutdown and startup (i.e., if a while loop, then it wouldn't actually shut down?). Finally, systemd is available only from the Jessie versions of Raspbian OS.

This would also need to be run in the background (and if it throws an error, make sure it doesn't brick the whole system).

[gursi26]

@sgbaird Done setting this up on the cobot. I followed the instructions on the website but had to make a few changes. After running crontab -e to edit the crontab file, I added the following line.

@reboot sleep 30; python <path to file>

I found that the sleep 30 call was necessary since reboot is relative to when cron starts, which could be before other services like the internet. Can probably be reduced to a smaller amount of sleep time.

Also had to drop sudo to get it to work.

[sgbaird]

UPDATE: The blog post clarifies that etc/rc.local will not prevent the OS from starting if you use an ampersand, but systemd is recommended over rc.local.

I was looking back at this, because it seems to be a bit difficult to see the output from a terminal, motivated by debugging purposes. Within the crontab file, it's easy enough to log to a text file on the desktop for example:

@reboot /usr/bin/python3 /home/pi/Desktop/my_file.py > /home/pi/Desktop/log.txt

However, in order to see the active log, you would need to run a command to watch the file for updates. This would either require manually running something in a terminal, or perhaps having a systemd implementation on top of crontab.

[sgbaird]

UPDATE: The blog post clarifies that etc/rc.local will not prevent the OS from starting if you use an ampersand, but systemd is recommended over rc.local.

I was looking back at this, because it seems to be a bit difficult to see the output from a terminal, motivated by debugging purposes. Within the crontab file, it's easy enough to log to a text file on the desktop for example:

@reboot /usr/bin/python3 /home/pi/Desktop/my_file.py > /home/pi/Desktop/log.txt

However, in order to see the active log, you would need to run a command to watch the file for updates. This would either require manually running something in a terminal, or perhaps having a systemd implementation on top of crontab.

EDIT: not sure if rc.local is actually not recommended in general, and perhaps systemd is supported on Ubuntu.

Then again, here is a recommendation that still uses crontab:

• https://askubuntu.com/questions/735935/running-command-at-startup-on-crontab
• https://www.reddit.com/r/linuxquestions/comments/110766f/is_there_a_way_to_make_cron_run_a_script_in_a/
• https://unix.stackexchange.com/a/564491/432417

gnome-terminal -- /bin/sh -c '/path/to/script; exec bash'

[sgbaird]

UPDATE: The blog post clarifies that etc/rc.local will not prevent the OS from starting if you use an ampersand, but systemd is recommended over rc.local.

I was looking back at this, because it seems to be a bit difficult to see the output from a terminal, motivated by debugging purposes. Within the crontab file, it's easy enough to log to a text file on the desktop for example:

@reboot /usr/bin/python3 /home/pi/Desktop/my_file.py > /home/pi/Desktop/log.txt

However, in order to see the active log, you would need to run a command to watch the file for updates. This would either require manually running something in a terminal, or perhaps having a systemd implementation on top of crontab.

[sgbaird]

The previous command, with or without @reboot prepended, does not seem to work. Just a normal desktop appears.

From what I understand, these two tasks should run independently.

EDIT: I think I'm supposed to run crontab to apply latest changes (?). I checked the crontab logs

• https://askubuntu.com/questions/56683/where-is-the-cron-crontab-log
• https://superuser.com/questions/247803/cron-ignoring-an-update-to-crontab

Overall confused.