I’m reaching out in hopes of getting some help with an issue I’m facing on a fresh install of Rocky Linux 9.3 (minimal ISO). I’ve created a custom systemd service to run a Python script at boot. The service works fine when manually started with systemctl start myscript.service, but for some reason, it doesn’t start automatically on reboot despite being enabled with systemctl enable myscript.service.
Here are a few details:
The service is located at /etc/systemd/system/myscript.service
I’ve confirmed it’s enabled with systemctl is-enabled
The script has execute permissions and works when run manually
There are no apparent errors in journalctl -xe related to the service, but it simply does not execute at startup
The service is of type=simple and includes After=network.target
I’ve tried adding more explicit dependencies like After=multi-user.target and even experimented with different WantedBy targets in the [Install] section. Still no luck.
Is there something specific to Rocky Linux 9.3 or its boot process that I might be overlooking? Could SELinux or some system security setting be silently preventing execution? Any suggestions or insights would be greatly appreciated. I’m happy to provide more details or logs if needed.
Rocky 9.3 is no longer supported. The current version is 9.5 and soon 9.6. Would be best to update your system or download new ISO’s.
As for the systemd service, you may need to try differenr types instead of simple, for example oneshot or forking to check/test until your service runs.
As iwalker posted earlier 9.3 is not supported but I had this same issue just a couple of days ago with 9.5. I was unable to come up with a solution for this exact use case, but I did come up with a work around that does the job.
But first, what does your python script do? If the script is trying to run something that’s service is not running yet the script may fail. I would look into dependencies in the script and see what correlating service you might need and add those to the After= field.
Have you tried After=default.target? You could also try to add a sleep to the myscript.service file. Something like:
ExecStartPre=/bin/sleep 10
Or adding a sleep to the beginning of your python script could work too.
The issue could very well be that SELinux is blocking access. Could you please share the ouput of systemctl status yourscript.service and journalctl -xe | grep AVC and journalctl -u yourscrip.service?
Now all that being said, I tried these things and was still unable to get my service to run my script. Same issue as you are having, it just simply didn’t run. It appears to be a permissions issue with that directory and my user account. I was able to fix the issue by changing this service from a system service to a user system service and set up my user account to linger so that my user could run the service and script before I logged in.
Here is what I did:
I put the service and the script into ~/.config/systemd/user
After=default.target vboxdrv.service(your dependencies will vary).
Make sure that your user is the owner of the files so that your linger user can run them.
When you enable the service with systemctl make sure to add the --user argument:
systemctl --user daemon-reload
systemctl --user enable youscript.service
systemctl --user start yourscript.service
If you want to keep the sleep in the myscript.service config file change it to this:
ExecStartPre=sleep 10
It appears I have figured out the issue I was having with my script running on boot as a system service. As @gerry666uk stated above, it all came down to the service script variables. I figured I would post my fix in case it helps anyone else.
I have a script to start two lab vms on my Rocky machine. Abiding by best practices, those VMs are owned by my user and not root. I scrapped the idea of a user service because as it turns out, linger does not work the way I was hoping. You have to log in initially in order to activate the linger session so it did me no good on boot. I placed my script back in /usr/local/bin/ and after a few days of troubleshooting I found the following:
ExecStart= was set to /bin/bash /usr/local/bin/myscript.sh. Since the VMs are owned by myuser I have to use myuser to run the ExecStart function. For simplicity sake I changed this to just bash and the script was able to run.
I originally had Group=myuser under the User= variable, I removed this so there would be no group specification.
Type= was set to simple. I changed this to Type=oneshot as this is a one time execution.
RemainAfterExit=yes This was the big one. Without it, the VMs would abort after startup because the parent service marked itself as inactive (dead) when the script completed. This caused the controlling session to be lost. RemainAfterExit=yes solved that issue for me.
Sorry for the long post, but I hope this helps someone! I’m still learning, so feedback is welcome.
