this post was submitted on 04 Jul 2024
6 points (87.5% liked)

Linux Questions

1149 readers
8 users here now

Linux questions Rules (in addition of the Lemmy.zip rules)

Tips for giving and receiving help

Any rule violations will result in disciplinary actions

founded 1 year ago
MODERATORS
possiblylinux127
6
[Solved] How can I make a custom .service run as root? (reddthat.com)
submitted 4 months ago* (last edited 4 months ago) by [email protected] to c/linuxquestions
19 comments fedilink hide all child comments
 

cross-posted from: https://reddthat.com/post/21668140

I have a VPN daemon that needs to run before the client will work. Normally, this would have been set up automatically by its install script, but the system is immutable.

I've created the systemd service via sysyemctl edit --force --full daemon.service with the following parameters:

[Unit] 
Description=Blah
After=network-online.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/env /path/to/daemon

[Install]
WantedBy=multi-user.target

I've verified that the daemon is actually executable, and it runs fine when I manually call it via sudo daemon. When I try to run it with sudo systemctl enable --now daemon.service, it exits with error code 126.

What am I missing?

Edit: Typo, and added the relevant user and group to the Service section. Still throwing a 126.

Solution: the system wanted /usr/bin/env in ExecStart to launch the binary. The .service file above has been edited to show the working solution.

top 19 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (4 children)

If that is your full .service file you are missing the directive to tell the daemon what user to run under. Under service try adding

User=root

Group=root

Before the ExecStart command line.

[–] [email protected] 4 points 4 months ago* (last edited 4 months ago) (2 children)

Is that necessary for processes running as root? AfaIk, root is default.

Keywords should be in CamelCase format, thus the space in Wanted By is wrong.

[–] [email protected] 3 points 4 months ago (1 children)

Honestly can't believe I completely missed the space in Wanted By. This is likely the bigger culprit to the failed to run error. Poster above me is correct should read

WantedBy

[–] [email protected] 2 points 4 months ago (1 children)

It's an autocorrect typo. It's actually WantedBy in the file.

[–] [email protected] 2 points 4 months ago

Would have been nice if this would have been the error.

[–] [email protected] 2 points 4 months ago

Foiled by autocorrect! There's no space in the original file, and I've edited my post to reflect that.

[–] [email protected] 4 points 4 months ago* (last edited 4 months ago) (1 children)

On that, make sure it's in the root systemd path. Something like /etc/systemd/system/blah.service, placing it in the user systemd service path (~/.config/systemd/user/) will cause permission errors as it'll try accessing the root user from the current user.

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago) (1 children)

Thanks, I verified that it's in the correct place. Still throwing a 126 (see the modifications in the edit).

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

What's the specific VPN service? I'll check their docs.

[–] [email protected] 1 points 4 months ago (1 children)

Private Internet Access

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

I assume so, but just to be sure, have you run sudo systemctl enable blah.service then reboot? It'll symbolic link to the systemd auto start service and run it at boot.
Also, make sure everything is marked as executable; especially whatever you have "/path/to/daemon" set as. sudo chmod +x /path/to/daemon
Restart the service or reboot then :
sudo systemctl status blah.service

[–] [email protected] 2 points 4 months ago (1 children)

Yep, more specifically I tried sudo systemctl enable --now daemon.service. Gives the same error, and maybe that's because it's some kind of binary.

sudo /bin/bash /path/to/daemon throws the same error, but sudo /path/to/daemon does not. However, if I drop , /bin/bash from the service file, it throws a 203 error instead.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

Is the daemon a binary? If so drop the bash part and try sudo chmod 755 /path/to/daemon.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

Tried that, back to 203/Exec error. It's like ExecStart wants me to specify a program to launch it, and bash clearly isn't it.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

Try ExecStart=/usr/bin/env /path/to/daemon
Also what's the output of ldd /path/to/daemon & sudo systemd-run /path/to/daemon ? Maybe check systemctl show-environment. Maybe try adding Type=simple , this tells systemd that the service will fork.

If that fails, we could try ExecStart=/usr/bin/strace -f -o /tmp/daemon_strace.log /path/to/daemon for stactrace & ExecStart=/bin/sh -c '/path/to/daemon > /tmp/daemon.log 2>&1' to log the daemon.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

Omg, adding /usr/bin/env worked. Launched the daemon, and the client is able to launch and connect a WireGuard tunnel.

systemctl show-environment lists /usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin on the PATH, so maybe that's why that worked...? (I'm going to have to go read up on env).

Either way, I did a reboot to verify, and it's definitely running. Now I just need to tweak it a bit so it tries to reconnect if the network drops out, but holy shit, I appreciate the help.

[–] [email protected] 3 points 4 months ago

Good to hear that it worked.
To explain env, typically when systemd is running a service it only provides a very minimal environment. When using env it passes more of the environment variables and whatnot from userspace, so it's likely that the binary daemon was looking for specific environment variables and it returned an empty string and that's what caused error, it's also useful if the daemon's location changes during runtime or if it's not in a standard location.

[–] [email protected] 2 points 4 months ago

I added the relevant user and group, and it's still throwing a 126. I checked the daemon itself, and it looks like it's a pre-compiled binary. Manually running /bin/bash /path/to/daemon gives the same error, but sudo /path/to/daemon starts the daemon.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

Does the command in ExecStart work in a root environment, e.g. sudo -i?