Crontab suddenly doesn't start jobs

Question

I'm suddenly having crontab issues, I didn't do anything other than change the script names and then change them in crontab as well so they all natch, the scripts work if I start them manually, so i'm assuming crontab doesn't start them for whatever reason. The scripts launch two python discord bots with the discord.py async branch which both use infinite event loops

crontab entries:

1st sh script that runs with the bash interpreter:

2nd sh script that also runs with the bash interpreter:

I am at a loss here so any help is appreciated, thank you!

Answer 1

You can help yourself by collecting any error messages that are generated when cron runs your scripts. As you're aware, your shell will send error messages to the stderr stream when they occur. When you run the program from your terminal screen, this stderr stream goes to your terminal, and you see it. However, your cron job does NOT run under your userid, and its stderr stream does NOT go to the screen.

Fortunately, Linux allows us to "redirect" the stderr stream, and we can redirect it to a file on our system. Doing this is very simple, but the command itself will seem arcane until you study it for a bit. You can redirect the error messages from your cron jobs by changing your crontab file as follows:

@reboot /home/pi/launchjuvia.sh >> /home/pi/cronjoblog 2>&1 
@reboot /home/pi/launchfuta.sh >> /home/pi/cronjoblog 2>&1 

After reboot, you can inspect the file /home/pi/cronjoblog, and read any error messages. If you have trouble deciphering the error messages, feel free to post them here & we'll try to help.

A coupla' other notes:

1. I don't think you need to call out bash in your crontab.
2. I don't understand what you're doing with the first line in your crontab. If you're trying to schedule a reboot recall that sudo is normally required (i.e. sudo reboot instead of reboot). In any case, I'd recommend you resolve the errors in your script first, then tackle your scheduled reboots once you have that sorted.
3. @Ingo's answer also has merit. systemd is technically superior to cron in some respects - an important one being that it has knowledge of resource availability during the boot process. However, cron is (IMHO) simpler, and inserting a sleep command in your crontab will usually resolve resource availability issues. For example:

@reboot /bin/sleep 10; /home/pi/launchjuvia.sh >> /home/pi/cronjoblog 2>&1 

This will postpone execution of your shell script for 10 seconds after cron starts, and by then the resources needed for successful execution may be available. You may need to experiment a bit to find the "best" value for sleep time.

Answer 2

You are using crontab to start programs on boot with option @reboot. In man 5 crontab you can read:

Please note that startup, as far as @reboot is concerned, is the time when the cron(8) daemon startup. In particular, it may be before some system daemons, or other facilities, were startup. This is due to the boot order sequence of the machine.

On Raspian Stretch starting system daemons and services are managed by systemd and it starts them parallel only controlled by dependencies. So a boot order sequence is not defined with systemd. If you change something, for example renaming services or installing additional services or removing some, then the boot order may change.

So it is possible that scripts suddenly doesn't start anymore with cron because they are missing services they need to run. These services are starting later now.

To avoid this problem you should use systemd unit files to make clean services managed by systemd with dependencies.

Answer 3

If this is the actual /etc/crontab file, shouldn't there be a field after the day-of-the-week that specifies the username under which the command should be run? See man crontab for help, and be sure not to confuse the actual /etc/crontab file with a user crontab file. They are different.