0

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: Crontab Entry Screenshot

1st sh script that runs with the bash interpreter: launchjuvia.py

2nd sh script that also runs with the bash interpreter: enter image description here

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

Ingo
  • 42,107
  • 20
  • 85
  • 197
Myronaz
  • 33
  • 4

3 Answers3

4

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.

Seamus
  • 21,900
  • 3
  • 33
  • 70
  • Alright. I see. Well I have to use bash because sh complains about paths, unfortunately adding the sleep part does not solve the problem, i've already got stderr redirected but nothing appears on my files, which tells me that the python modules do not run at all. As for the reboot line you were right, i forgot to put sudo in which explains why it wasn't restarting – Myronaz Feb 22 '19 at 21:04
  • @Myronaz OK... but your script contains a shebang for sh, so why are you calling bash ? And I just noticed that the first line of your script is cd /... why do you do that? As far as the redirect, maybe try adding this after your shebang line: >&2 echo "test stderr redirect" – Seamus Feb 23 '19 at 01:05
  • @Myronaz: Also remember that the "cron user" does not have the same environment vars as you do working from the command line. Therefore, it's a good habit to use full paths for all commands and file locations in cron jobs. – Seamus Feb 23 '19 at 01:09
  • "Fortunately, Linux allows us to 'redirect' the stderr stream" -> Would be more accurate to say "the shell", or more specifically bash or sh. Different shells in fact use different syntax for this (and e.g. bash includes sugar that sh doesn't, such as &>). What you've used is standard POSIX shell, which is good because it is the normal case on the Pi. – goldilocks Feb 23 '19 at 21:19
  • @goldilocks: Good point – Seamus Feb 24 '19 at 06:36
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.

Ingo
  • 42,107
  • 20
  • 85
  • 197
0

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.

bls
  • 520
  • 3
  • 5