This isn't necessarily a Pi-specific question, but might be applicable to general Linux. However, my hunch is that the Pi's uniqueness might have something to do with it.

I'm trying to run two scripts on startup on my Pi 4 (raspbian stretch).
One is a python 2 script (I have Python 2 and 3 installed on the Pi, but Python2.7 is run when you simply do python script.py), the other is a CLI app based on a python 3 module installed via pip3, midiroute. EDIT: The purpose of running both of these scripts at startup: 1) to start the samplerbox script , and 2) to loopback incoming midi from an attached Midi keyboard (native instruments komplete kontrol) back to its 5-pin output, if the keyboard is connected and listed as a midi device. Context: this allows me to control hardware connected via 5-pin midi as well as the software instrument that is samplerbox.

I remember having this issue before (in a different context, on an Ubuntu server), so I tried to find the full paths to the binaries that execute these scripts using

which python
which midiroute

This returns the full paths.

I then put these full paths into either crontab or a new .service file. However, when aiming to run them on startup, neither work.

The py script tells me it's missing a required module (which it isn't if i simply start the script using python script.py), like so:

  File "/home/pi/SamplerBox/samplerbox.py", line 27, in <module>
    import samplerbox_audio   # audio-module (cython)
  File "samplerbox_audio.pyx", line 51, in init samplerbox_audio
    import gv
ImportError: No module named gv

The other job logs an error that it can't find the required binary, like so: /home/pi/nl_utils/midi_redirect_kompletekontrol.sh: 7: /home/pi/nl_utils/midi_redirect_kompletekontrol.sh: midiroute: not found

any ideas as to how I can do this?


my crontab:

@reboot /usr/bin/python /home/pi/SamplerBox/samplerbox.py > /home/pi/nl_utils/logfiles/samplerbox.log 2>&1
@reboot sh /home/pi/nl_utils/midi_redirect_kompletekontrol.sh > /home/pi/nl_utils/logfiles/midi_route.log 2>&1

my .service:

pi@raspberrypi:/etc/systemd/system $ cat run_midi_routing_at_startup.service
Description=Run the midi routing script after startup once all other startup daemons have loaded.


  • You could help yourself by editing your question to add the lines from your crontab. ALSO: In general, if you can run something successfully from the command line, then you can also run it from cron. So - can you successfully run these scripts from the CLI? I've got a couple of hunches re the cause for your issue - I'll try to answer once you reply here.
    – Seamus
    Commented Dec 1, 2021 at 23:09
  • you're right, apologies. i figured it'd be a dead simple one so wasn't as thorough as i should have been. i'll upate the Q tomorrow, i've packed up my Pi rn...
    – nikUoM
    Commented Dec 2, 2021 at 0:18

1 Answer 1


There are two possibilities that come to mind:

  1. By using which python, you may have taken the incorrect path for the script that uses Python3. You will need to use the appropriate full path for Python 3; e.g. usr/bin/python3. The following cmd will show what's available:

    ls -l /usr/bin | grep python

    NOTE: If you want to change which version of Python is used as the default on your system, use the update-alternatives command. Here's an example of how update-alternatives is used.

  2. If your script runs successfully from the command line/interactive shell, but fails silently when run under @reboot in your crontab - or in a systemd unit, the cause may be a dependency issue. By that, I mean only that when (for example) cron tries to run your @reboot script, the init system (systemd for recent RPi OS) may not have yet started it. For example: your script calls for a network connection, but the network has not yet been initialized during the boot process.

    In cron, this can often be cured by inserting a sleep command in front of your script call. This simply postpones the start time of your objective script by a few seconds, giving the init system time to get all other services started.

    In a systemd unit, one or more predicates (e.g. After=...) can be added to your unit file that will ensure it's not started until a required service is available.

    Another symptom to check is for a script that runs successfully from the CLI but fails when run as a cron job. This symptom suggests that the failure is due to the substantial differences between the CLI user's rich environment in an interactive shell, and the austere environment in cron.

  3. Other issues:

    If the suggestions above don't cure your issue, more details in your question may be needed. You should consider adding a redirect in your crontab to capture any errors generated. A general form four your @reboot entry could be as follows:

    @reboot sleep 30; /usr/bin/python3 /path/to/myscript.py >> /path/to/mylog 2>&1
  • hi there, thanks for your answer. as you can see in my edit, i suppose i took 1. and 3 as read, it would have been useful for me to specify them from the get-go. I wasn't aware of sleep, however, unfortunately that didn't fix my crontab -- I'm still getting the same errors, namely a missing module gv in the python script and a missing app midiroute in the second script. To reiterate, both of these work in an interactive shell
    – nikUoM
    Commented Dec 2, 2021 at 13:34
  • @nikUoM: I'm not sure I understand your comment wrt i took 1. and 3 as read.... Moving on, the new data suggests that the issue may be a difference in the environment. Were you aware that your interactive shell & cron have vastly different set of env variables? Verify by running printenv fm the CLI, then run printenv in a cron job: * * * * * printenv > /home/pi/cronenv.txt 2>&1. Find the env var that is peculiar to your scripts, or see this
    – Seamus
    Commented Dec 2, 2021 at 19:18
  • my comment means, yes you need to redirect your output, and yes, you need to put the full path in there, but i thought the knowledge of these facts was implied in the way i formulated my question. apologies!
    – nikUoM
    Commented Dec 2, 2021 at 23:30
  • @nikUoM: Have you looked into the environment diffs?
    – Seamus
    Commented Dec 3, 2021 at 4:28
  • hey @Seamus. Sorry for taking so long -- but you're right, your hunch was correct. I stuck the calling of my scripts into separate shell scripts, containing the code referenced here - ibm.com/support/pages/cron-environment-and-cron-job-failures - and it worked! Thanks for your help.
    – nikUoM
    Commented Dec 22, 2021 at 21:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.