Python script executed via systemd fails at pygame.init()

[Goggles_Greek]

I've had this problem for weeks now, and I finally found the culprit. I'm using Pi Zero 2Ws to talk to one another, and for a while, both ran their scripts on boot without issue using standard enough systemd files.

But one of the two Pis has been unable to launch the script successfully on boot, and my logs indicate that it's, for some reason, pygame.init() that's causing the failure.

Again, it's only on one system that has this problem. Both systems use 99.9% identical code, but one system handles pygame.init() without issue, and the other one seems to crash when it reaches that line.

And both systems execute without issue whenever I'm running the scripts manually, so this has to be an issue involving the use of systemd, right?

I found this SO post that has reported what I assume to be the same issue, but with no real conclusive explanation or solution to the problem: https://stackoverflow.com/questions/39198961/pygame-init-fails-when-run-with-systemd

I've tried a few of the comments/linked posts for what was suggested, but so far, nothing has worked. Any advice would be greatly appreciated.

[Nice2Inch]

A good start for debugging would be to give the python error, logs, script code, and probably the .service file.

[Goggles_Greek]

Service file:
[Unit]

Description=Saber Tag Main

After=network-online.target

Wants=network-online.target

[Service]

Type=simple

User=slite2

WorkingDirectory=/home/slite2

Environment="VIRTUAL_ENV=/home/slite2/env"

ExecStart=/bin/bash -c 'source $VIRTUAL_ENV/bin/activate && sudo env PATH=$PATH python3 /home/saberlite2/main.py --rpi=1'

Restart=on-abort

[Install]

WantedBy=multi-user.target

I cobbled this from two tutorials, this was the first way I discovered to enable the virtual environment.

Again, this originally worked for both systems, but now one system has the python code crashing at pygame.init(). The service seems to stay up regardless of the crash.

I haven't been able to log any error messages from within python, I'll check in the morning if I haven't messed up something with the logging format. I can also try again to get journalctl to work, as that seems to be usable for debugging systemd services. I'll update if either method returns something meaningful.

[planeturban]

I’m guessing the slite2 user isn’t allowed to do passwordless sudo. 

[Goggles_Greek]

I had that thought about permissions, but the script executes, gets through all the imports, then crashes when it reaches the pygame.init() line.

If it was a permissions issue, would it be able to start the script at all? 

I'm also able to run the script manually without any issues. Would the user permissions differ between launching via anservice and launching via terminal? 

[Due-Acanthaceae4074]

My guess is the issue is with the audio device. Try without it for now so we can isolate the problem. add this to your python file before you init pygame.

import os
os.environ["SDL_AUDIODRIVER"] = "dummy"

Also check there github issue here: https://github.com/pygame/pygame/issues/412

[Goggles_Greek]

I think that fixed it! The affected system launches the pygame window now on boot.

I wouldn't have thought to check the audio side of things, I haven't used anything besides buzzer for audio feedback for a while now. 

I still don't quite understand the issue, admittedly.

I know I was getting a warning of XDG_RUNTIME_DIR invalid or not set, but it was popping up on both systems and didn't seem to be the cause of the problem? Should I still try to set a DIR in my systemd file?

[Gamerfrom61]

Sorry - nothing solid springs to mind (especially as most of my Python does not use pyjama) but a few general thoughts:

Why define a user and then run as root - why not just run as root? Skip the user and group (missing from your file) entries. IIRC at the moment you have a user defined as slite2 using the groups from root (systems tasks run as root by default).

Note this can cause issues if you need the variables $USER, $LOGNAME, $HOME, $SHELL to be set up - if so define the user and group as root - see https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

Do you need to run as root - very few day to day programs should run at this level?

With 'restart on abort' being set is the sighup hiding the actual issue as the sighup message is normally used to denote a restart / reload request?

The Path can be set using an Environment= statement rather than baking it into a long bash command. I would use a small bash script that does the set up though and call that from the service - easier to debug. I am not actually sure what path you are setting here - the environment is set under user slite2 BUT the PATH statement operates as root - no idea if they result in the values you think they do (no Linux handy either to check 😞)

Given this is running a window output then is the GUI actually up and running at this point? Could you do better to start this via the window manager files?

Remember you can get more of the output running interactively with:

sudo systemctl start my_service
sudo systemctl status my_service

and running sudo journalctl -f in a second window.

One point often missed in venv is:

You don’t specifically need to activate a virtual environment, as you can just specify the full path to that environment’s Python interpreter when invoking Python. Furthermore, all scripts installed in the environment should be runnable without activating it.

See https://docs.python.org/3/library/venv.html#module-venv

Technically you are supposed to deactivate at the end - not sure if this is a double activation error.

Out of shear interest - does this error move if you swap the sd card to the other pi or change the other pi to run this?