crontab troubleshooting

Volumio SW (V2.609) on Raspberry.Pi 2


My task is to set up and automatic reboot at a specific time.
The reason for that: I lose every once in awhile WiFi connection. My device is behind a wall and is not easily accessible. Because of that I have an RF-Remote Control attached which is interfaced via an Python-Script to control volume etc.
My idea is to reboot Volumio once a day.

I got crontab working as suggested by Michelangelo:

“apt-get update && apt-get install -y cron” -> worked fine

Created a with root privileges "crontab -e
41 * * * * /sbin/shutdown -r +2

Reboot at a specific time works also fine - no problem. But starting the Python-script @reboot will not work.

I have spent hours but I find no solution to this issue - I am not even able to get the cron error logging to work.
With a regular Raspberry installation I can set up logging under “/etc/syslog.conf” to find later on a log file under: “var/log/cron.log” (syslog.conf is missing)

Sofar I am not even successful getting logging to work. Leave alone starting the script.

All my settings I run as user “root” I have created a batch file to start the script. Works fine when used via CLI. Like so:
“root@volumio-1:/home/volumio# /home/volumio/” (This starts the Python script w/o problem)

but not when call it via crontab!

Any idea?

Thank you very much for your help.

==== crontab in use - one of many different configurations ==============================
41 * * * * /sbin/shutdown -r +2 <---- works
@reboot nohup /root/ > /root/rl1.txt <-----does nothing

Volumio is systemd based.

You’re much better off to simply create a systemd service that starts automatically at boot up. I would consider using @reboot in crontab to be heavily deprecated on a distro running systemd. Systemd services are far more powerful and flexible.

Have a browse through the following, there are examples near the end: … rvice.html

For a script that remains executing indefinitely you want to use simple service (Type=simple) for the type of service, as in Example 2 at the bottom of that article. (I assume you want to leave it running all the time since you used nohup)

Something like this should work:

Description=Python Remote

ExecStart=/bin/bash /root/


Save this as /etc/systemd/system/python-remote.service then run sudo systemctl enable python-remote.service so that it will start on boot and optionally sudo systemctl start python-remote.service to start the new service immediately.

systemctl documentation: … emctl.html

The most commonly used systemctl options are enable, disable, start, stop and restart.

thank you very much for your speedy reply.
Unfortunately that is what I have tried a few month ago - > please refer to my post:
“Failed to start Volumio Backend Module”

Which would not work - since I got stuck there I decided to go back to work with crontab.
In Volumio < 2.0 that worked like a charme.

Nevertheless I will try your version once more.

I can’t see any reason why running your script would not work from a systemd service. I run scripts from systemd services all the time.

It looks like you have a shell script wrapper for your python script ? You might be better off running the python script directly like this:

ExecStart=/usr/bin/env python /root/

This will use env to find the default system install of python and execute the python script directly without using a shell, which would work as long as your bash script doesn’t do anything other than launching the python script. (Hard to know without seeing your script)

Hello, and thank you again for your quick reply.
In the meantime I have tried out your suggestion(s):
The good news: I do not get an error message with
root@volumio-1:/home/volumio# systemctl enable python-remote.service
or this:
root@volumio-1:/home/volumio# systemctl start python-remote.service

later works great.
root@volumio-1:/home/volumio# systemctl enable python-remote.service
gives no error
but does not do anything upon reboot.

When I look at the status of systemd with:
root@volumio-1:/home/volumio# systemctl status
I get this output:
● python-remote.service - Python Remote
Loaded: loaded (/etc/systemd/system/python-remote.service; enabled)
Active: active (running) since Thu 2019-12-19 19:29:07 UTC; 28s ago
Main PID: 8051 (python3)
CGroup: /system.slice/python-remote.service
└─8051 python3 /root/
I tried:

  • ExecStart=/bin/bash /root/


  • ExecStart=/usr/bin/env python /root/

No difference in outcome. Works when manually started - does not work upon reboot

What else can I try? Please find below error messages and python script

Thank you very much

Output of dmesg with:
root@volumio-1:/home/volumio# dmesg |grep systemd
[ 10.002756] random: systemd: uninitialized urandom read (16 bytes read)
[ 10.011486] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYS VINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
[ 10.011996] systemd[1]: Detected architecture ‘arm’.
[ 10.192051] systemd[1]: Inserted module ‘ipv6’
[ 10.194996] systemd[1]: Set hostname to .
[ 10.353581] random: systemd-sysv-ge: uninitialized urandom read (16 bytes read)
[ 10.478640] random: systemd: uninitialized urandom read (16 bytes read)
[ 10.589607] systemd[1]: [/lib/systemd/system/mpd.service:18] Unknown lvalue ‘ProtectKernelT unables’ in section ‘Service’
[ 10.589699] systemd[1]: [/lib/systemd/system/mpd.service:19] Unknown lvalue ‘ProtectControl Groups’ in section ‘Service’
[ 10.589776] systemd[1]: [/lib/systemd/system/mpd.service:20] Unknown lvalue ‘ProtectKernelM odules’ in section ‘Service’
[ 10.589877] systemd[1]: [/lib/systemd/system/mpd.service:23] Unknown lvalue ‘RestrictNamespaces’ in section ‘Service’
[ 10.685316] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[ 10.690237] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
[ 11.107094] systemd-udevd[177]: starting version 215
[ 13.733916] systemd-journald[170]: Received request to flush runtime journal from PID 1


my python code:

import paho.mqtt.client as mqtt #import the client1
import time as t
import keyboard # keyboard lib assumes to have kbd -> dumpkeys installed

#=========== MQTT stuff =========================================
#=========== Topic ==============================================
topic_Volume = “volumio-1/volume” # messages: [lauter,leiser]
topic_Play = “volumio-1/play”
topic_List = “volumio-1/list”

client = mqtt.Client(“P3”) #create new instance, RL: do not use key twice
client.connect(broker_address) #connect to broker

def on_log(client, userdata, level, buf):
print("log: ",buf)


#======== RL functions =============================================
def rl_publish(topic,volume):

if key == “help” :
mqtt_code= “lauter” # zuweisung f r Node-Red via mqtt
if key == “f14” :
mqtt_code= “leiser”
if key == “right” :
mqtt_code= “play”
if key == “left” :
mqtt_code= “stop”
if key == “esc” :
mqtt_code= “next”
if key == “enter” :
mqtt_code= “radio”
if key == “up” :
mqtt_code= “br-1”
if key == “down” :
mqtt_code= “Canada”
except KeyboardInterrupt:


Thank you once more for your help.

By means of debugging setup for “systemd” I found the problem related to my python script.
From what I understand it is a network issue. Volumio has not yet fully booted and my script wants to talk to my
MQTT broker.
That explains why my script would work fine when started manually.
I simply put an delay of 15 sec into my script and now it seems to work stable.

But I still have one more question in this regard: If “crontab” is outdated , how would I go about an scheduled reboot? Also with systemd?

Thanks a million

PS: Might be an idea for a plugin - my programming skills are not sufficient to do it myself

If you want to delay a service starting until the network is up you should add the following two lines in the [Unit] section of the systemd service:

See: … orkTarget/

You shouldn’t need a delay if you do this as the service won’t be started until the network is initialised.

I meant that using the @reboot option in crontab to run a command after rebooting is obsolete as it has very limited configuration possibilities - one problem that you have noted is that it cannot be told to wait until the network is up, whereas a systemd service has a lot of flexibility including waiting for the network to come up, if you tell it to.

Although there is also a systemd “timer” unit that can be created to run commands at certain times which technically obsoletes crontab I still like to use crontab for tasks scheduled to run at specific clock times. (I don’t use the @reboot option though)