systemd "status=203/EXEC" error when creating new service

Question

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 :

[Unit]
Description=ReadPressure

[Service]
ExecStart=/bin/bash -c 'python3 -u /home/pi/ReadPressure/ReadPressure2AndPostToMqtt.py'
WorkingDirectory=/home/pi/ReadPressure/
Restart=always
User=pi

[Install]
WantedBy=multi-user.target

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

Thanks

Answer 1

Try:

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

Answer 2

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

[Unit]
Description=LibreNMS SNMP Poller Service
After=network.target

[Service]
ExecStart=/opt/librenms/librenms-service.py -v -d
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/opt/librenms
User=librenms
Group=librenms
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

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

Answer 3

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

ExecStart="/bin/bash -c 'python3 bla blah'"

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.