# What's different about a crontab reboot?

I have a python script to log data from a USB weather station and present it via a flask front end. The USB on the pi (Pi2 model B) is flaky and occasionally hangs after 24-48 hours. The flask app doesn't seem to cope to well when my home broadband glitches out. To cope with both problems, I reboot the pi every night at 1 am through cron. I've also created an @reboot cron entry to run the python/flask app.

So, the problem I have is this:

• If I run the script manually, it works perfectly every time
• If I manually reboot with "shutdown -r now", it works perfectly every time
• When the reboot runs though crontab, it consistently 100% of the time time fails to initialize the USB interface and usually without an error message. (Any error seen is a "timeout" which is semi-normal so ignored by the app. The flask front end still works fine.)

Is there something different about a cron-initiated script and the interaction with the USB subsystem?

Tried unsuccessfully: usbreset app, writing to "authorized" file for the USB device. They don't break anything but they don't fix the problem either.

pi is running Linux 4.19.27-v7+ #1206 SMP

crontab for the weather station user: (just one line)

@reboot bash /home/pi/wd >/home/pi/wdstartup.log 2>&1

crontab for root: (one line again)

0 1 * * * /sbin/shutdown -r now

the weather station startup script:

#!/bin/bash
cd ~pi
cd weatherd
./usbreset /dev/bus/usb/001/004
sudo echo 0 > /sys/bus/usb/devices/1-1.4/authorized
sudo echo 1 > /sys/bus/usb/devices/1-1.4/authorized
sleep 60
cp wd.log wd.log.old
nohup python3 weatherd.py >& wd.log &
cd ~pi


1. You have a cron job to reboot your RPi every night at 01:00; e.g.
0 1 * * * sudo reboot (#or something similar; e.g. shutdown -r now)

1. You have a 2nd cron job to restart your app using the @reboot facility in cron; e.g.
@reboot /path/to/your/flask/app


If you're certain that your 01:00 reboot is being executed successfully, then your flask app may not be running for one or both of the following reasons:

1. You've not given cron a complete path specification for your flask app, and/or

2. Your system hasn't initialized/started all of the services needed to run your flask app when cron runs it.

1. When you run a cron job, it runs as a different user - not you, in other words. That means the environment is different, and things like your \$PATH may be incorrectly specified. That's a simple problem to overcome: Simply use a complete path specification to your flask app. For example:
@reboot /path/to/your/python /path/to/your/flask/app

1. When you run a cron job @reboot, use the sleep command to give your system a bit more time to initialize the required services. For example:
@reboot /bin/sleep 30; /path/to/your/python /path/to/your/flask/app

1. For reasons similar to those in #1. above, any output from stderr will be lost, which makes troubleshooting more difficult. That also is easily remedied; e.g.:
@reboot /bin/sleep 30; /path/to/your/python /path/to/your/flask/app  >> /home/pi/cronjoblog 2>&1


Which will append any stderr output to the file /home/pi/cronjoblog. If you want to write it somewhere else, simply substitute the file spec of your choosing.

Your question lacks a bit of detail that might have made it more clear. If this answer doesn't address the issues you're experiencing, please edit your question with the contents of your current crontab & anything else you feel may be relevant.

• Thanks for the response. In fact, the flask app does work and quite happily serves web pages and loads info from a Met Office web site, so there doesn't seem to be a problem there. It's the USB interface that doesn't work and I can't see why. – Steve Foster Jul 14 at 20:11
• @SteveFoster: "Doesn't work"??? You mean with cron, or all of the time? If cron-related, did you try the sleep command I showed? – Seamus Jul 14 at 22:32
• What I mean is that there's a background thread in the app that uses pyusb to read data from a USB weather station (...an ancient Oregon Scientific RMS300). When started from cron,after a cron-automated reboot, the USB interface fails. It seems to fail silently, i.e. there is an occasional message but only of a type that can occur at any time with this device. – Steve Foster Jul 15 at 17:52
• Having said all that, I had a hunch last night. The reboot is set for 01:00 which would be 00:00 GMT and I wondered if automated housekeeping , either in the app or the pi OS, was interfering. I changed the reboot time to 02:30 and, amazingly, everything worked this morning! I'm watching for a few days to see if this was a fluke or not. – Steve Foster Jul 15 at 17:54
• @SteveFoster - let us know how that works out, but I'd suggest you consider making that a separate (new) question. – Seamus Jul 15 at 22:37