Why am I having problems starting my service in Red Hat Enterprise Linux 8?

Question

I'm having issues in setting up services that run with my user in Red Hat Enterprise Linux 8. To debug it I created a small shell script with:

/home/d608771/my_service.sh

With file permissions set as:

-rwxrwxrwx.  1 d608771 d608771  135 Sep  4 12:55 q.sh

And the contents are:

#!/usr/bin/env bash
filename="/home/d608771/tmp/hello-$(date +"%Y_%m_%d_%H-%M-%S").txt"
touch $filename
echo "Hello World" > $filename

Then I created this service:

/usr/lib/systemd/system/my_service.service

With file permissions set as

-rw-r--r--. 1 root root  347 Jan 20  2022  my_service.service

And the contents are:

[Unit]
Description=Service
 
[Service]
ExecStart=/home/d608771/my_service.sh
Type=oneshot
 
[Install]
WantedBy=default.target

But when I try to start the service:

systemctl --user daemon-reload
systemctl --user enable my_service.service

I get the following:

Failed to enable unit: Unit file my_service.service does not exist.

And then with this:

systemctl --user start my_service.service

I get:

Failed to start my_service.service: Unit my_service.service not found.

I also tried with sudo:

sudo systemctl daemon-reload
sudo systemctl enable my_service.service
sudo systemctl start my_service.service

And I get this:

Job for my_service.service failed because the control process exited with error code.
See "systemctl status my_service.service" and "journalctl -xe" for details.

And then this:

Sep 04 14:12:52 GBUKSDV-l608771 systemd[1]: my_service.service: Changed dead -> failed
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Trying to enqueue job my_service.service/start/replace
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Installed new job my_service.service/start as 1092842
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Enqueued job my_service.service/start as 1092842
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Failed to set blkio.weight: No such file or directory
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Passing 0 fds to service
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: About to execute: /home/d608771/my_service.sh
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Forked /home/d608771/my_service.sh as 540558
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Changed failed -> start
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: Starting my_service service...
Sep 04 14:12:59 GBUKSDV-l608771 systemd[540558]: my_service.service: Executing: /home/d608771/my_service.sh
Sep 04 14:12:59 GBUKSDV-l608771 systemd[540558]: my_service.service: Failed to execute command: Permission denied
Sep 04 14:12:59 GBUKSDV-l608771 systemd[540558]: my_service.service: Failed at step EXEC spawning /home/d608771/my_service.sh: Permission denied
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Child 540558 belongs to my_service.service.
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Main process exited, code=exited, status=203/EXEC
Sep 04 14:12:59 GBUKSDV-l608771 systemd[1]: my_service.service: Failed with result 'exit-code'.

Any idea what can be wrong?

Answer 1

1. You placed your service file into /usr/lib/systemd/system/my_service.service. This is the directory for system service files that are parts of RPM packages: a local custom system service should go to /etc/systemd/system/my_service.service instead, and a local user service should go to /etc/systemd/user/my_service.service if it's meant for all users, or to ~/.config/systemd/user/my_service.service if it's for your own user account only.

2. Running systemctl --user enable my_service.service looks for a user service to enable. Since you don't have a user service by that name, the command fails.

   When you run sudo systemctl enable my_service.service and sudo systemctl start my_service.service, you are enabling and starting a system service, and based on the directory your service file is located in, that's what your my_service.service is.

3. A system service will be run as the root user, unless the service file specifies some other user to run it as. But your actual /home/d608771/my_service.sh script has several flaws:

   • It is not located in a system executable directory like /usr/local/bin, but in a regular user's home directory. That will cause it to have a default SELinux type of user_home_t. A system service should not execute things off user's home directories, so this might be blocked by default SELinux rules.
   • It is not owned by root or other system user, but a regular user. This means the user owning the file might be able to replace it later with a more nefarious script or binary. This is another reason why SELinux might block it.
   • It is world-writeable. Absolutely any user could append or overwrite the script with evil content, which would be then run as the root user... this would make it very easy for any local user that wants to try a little "hacking" to gain root access on your system. Yet another reason why SELinux might stop this script from running.

Answer 2

Failed to enable unit: Unit file my_service.service does not exist.

You installed the .service unit as a system service but tried to start it as a --user service. The "system" and "user" service managers have no relationship and they read unit files from different locations – user-level units are read from:

• ~/.config/systemd/user/
• /etc/systemd/user/
• /usr/lib/systemd/user/

(Generally, you should not install "system-level" units to /usr/lib/systemd/system either, unless you're packaging some software for your Linux distribution. Instead use /etc/systemd/system for all your local configurations.)

Sep 04 14:12:59 GBUKSDV-l608771 systemd[540558]: my_service.service: Failed at step EXEC spawning /home/d608771/my_service.sh: Permission denied

I suspect that SELinux might be involved here – the default policy might not allow system services to run from home directories. Check your dmesg for any AVC deny messages.

But this is probably moot as different rules will apply to --user services.

Answer 3

Other answers do a good job of explaining the differences between user and system services, and the reasons for the error messages with systemctl enable.

I saw something which might explain the error: Failed at step EXEC spawning /home/d608771/my_service.sh: Permission denied (this error does probably mean that the file at /home/d608771/my_service.sh is not readable and/or executable)

You said:

I created a small shell script with:

/home/d608771/my_service.sh

With file permissions set as:

-rwxrwxrwx.  1 d608771 d608771  135 Sep  4 12:55 q.sh

In your question you showed us q.sh but you didn't share the permissions of my_service.sh... maybe just a typo, but, are you sure it's executable? Do you accidentally have both a q.sh and a my_service.sh?

Try

chmod +x /home/d608771/my_service.sh