.service or crontab for shell script calling python-CLI app and/or python script failing

Question

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?

EDIT:

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
[Unit]
Description=Run the midi routing script after startup once all other startup daemons have loaded.
After=default.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/home/pi/nl_utils/midi_redirect_kompletekontrol.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

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