I've created a new service for a Python script that works when running standalone but gives errors below when run through systemd :

Oct 02 12:17:09 raspberrypi systemd[1]: Started Read pressure And Post to mqtt.
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Main process exited, code=exited, status=203/EXEC
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Unit entered failed state.
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Failed with result 'exit-code'.
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Service hold-off time over, scheduling restart.
Oct 02 12:17:09 raspberrypi systemd[1]: Stopped Read pressure And Post to mqtt.
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Start request repeated too quickly.
Oct 02 12:17:09 raspberrypi systemd[1]: Failed to start Read pressure And Post to mqtt.
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Unit entered failed state.
Oct 02 12:17:09 raspberrypi systemd[1]: ReadPressure.service: Failed with result 'exit-code'.

The service was created in "etc/systemd/system/ReadPressure.service. it has executable rights.

The services looks like :


ExecStart=/bin/bash -c 'python3 -u /home/pi/ReadPressure/ReadPressure2AndPostToMqtt.py'


Any ideas why im getting the errors? The operating system is Raspbian.


  • A related question is unix.stackexchange.com/questions/458648 .
    – JdeBP
    Oct 3, 2018 at 11:11
  • 5
    Why are you starting a bash that is calling python? You can start python directly with ExecStart=/usr/bin/python3... or wherever your python3 binary resides.
    – Thomas
    Oct 3, 2018 at 11:18
  • Tried starting directly too. I saw a example like that so i tried it to see if it gives me different results. Oct 3, 2018 at 11:37
  • 1
    according to hte docmentation "203 EXIT_EXEC" says "The actual process execution failed (specifically, the execve(2) system call). Most likely this is caused by a missing or non-accessible executable file." I guess it cant find the python file? in the log it says " Started Read pressure And Post to mqtt" but the file is named "ReadPressure2AndPostToMqtt.py". Do you think that could be part of the problem? i dont know how to correct it, any ideas? Oct 3, 2018 at 11:39
  • What does type python3 return?
    – Thomas
    Oct 3, 2018 at 12:10

7 Answers 7



pi@raspberrypi:~ $ systemctl status ReadPressure.service

Paraphrasing @Ingo from I fail to start a python program in Thonny on startup

The error message (code=exited, status=203/EXEC) is often seen when the script itself or its interpreter cannot be executed.

It could have these reasons:

  • wrong path to script (e.g. /home/py/ReadPressure2AndPostToMqtt.py)

  • script not executable

  • no shebang (first line)

  • wrong path in shebang (e.g. /bin/python3)

  • internal files in your script might be missing access permissions.

  • SELinux may be preventing execution of the ExecStart parameter; check /var/log/audit/audit.log for messages of the form: type=AVC msg=audit([...]): avc: denied { execute } or in the output of ausearch -ts recent -m avc -i.

  • You have the wrong WorkingDirectory parameter

  • 3
    Had the same issue as the OP and indeed, forgot the shebang stuff in my script...
    – GeertVc
    Oct 22, 2021 at 14:40
  • To add to the point "script not executable" - when uploading file from Windows (FTP, scp...), make sure that the source file has LF (instead of Windows default CRLF) line separators. Nov 16, 2022 at 1:23
  • no shebang (first line) was the problem, Thanks Sep 3, 2023 at 8:40

Another possible reason for status=203/EXEC might be SELinux. In my case I had a unit file that launched a python script:

Description=LibreNMS SNMP Poller Service

ExecStart=/opt/librenms/librenms-service.py -v -d
ExecReload=/bin/kill -HUP $MAINPID


The python script had SELinux type descriptor httpd_sys_content_t, which was not allowed to be executed. I saw the error by using audit2why < /var/log/audit/audit.log which looked like

type=AVC msg=audit(1631272189.992:1032): avc:  denied  { execute } for  pid=2873 comm="(rvice.py)" name="librenms-service.py" dev="sda3" ino=714393 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file permissive=0

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

I ended up editing the Security context.

Non permanent edit (for testing):

chcon -t bin_t /opt/librenms/librenms-service.py

Permanent edit:

semanage fcontext -a -t bin_t '/opt/librenms/librenms-service.py'
restorecon -Fv /opt/bin/librenms-service.py
  • "chcon -t bin_t" did it for me. Is there any reason you call it a "non-permanent" solution? Mar 17, 2022 at 17:22
  • chcon will label the file until a relabeling will occur (upgrades). The permanent solution is using semanage and then relabel manually with restorecon Mar 18, 2022 at 18:55
  • I assume that "relabeling" is not something that happens for user-created services, by default? Mar 21, 2022 at 18:47
  • 1
    Since there are default lables for every default directory, files in /opt will inherit from default /opt label. So your user created service will be relabeled on upgrades. Mar 22, 2022 at 9:39

You may need to quote your command, e.g.:

ExecStart="/bin/bash -c 'python3 bla blah'"
  • thank you, this solved my problem with jupyter [in a conda environment] Apr 7, 2021 at 16:07

In my case I got the following error: ... /usr/bin/env: 'python3\r': No such file or directory based on the shebang:

#!/usr/bin/env python3

Took me some time to notice the Carriage return '\r'. After deleting it everything worked fine.


For me, the issue was actually a previous service of the same name I had tried to install earlier. I could tell that that was the issue by the references to the old service in the log. Removing the old service and running 'systemctl daemon-reload' fixed the issue for me.


In my case the bash script to start was on a different physical drive than the one in which the system resides.

Putting the script under /usr/local/bin fixed the issue, although I'm not sure why.


I had the error when the binary belong to a root user with permission 700 e.g. hadn't execution permission for others. The service unit use own user so it can't start the service. I made chown o+x /sbin/my_service and it worked after this. Just wondered that nothing meaningful was written to logs I had to guess. Maybe systemd needs for some debug flag, if anyone know please let me know.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .