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

Edit 2: Added script modifications. Daemon appears to be some kind of pre-compiled binary.

Solution: ExecStart wanted /usr/bin/env to launch the binary. The service file above has been edited to reflect the correct solution. See this post for further discussion.

  • _spiffy@lemmy.caEnglish
    5·
    3 days ago

    Typically you instruct systemd to run a service as a specific user/group with a User= and Group= directive in the [Service] section of the unit file.

    The error code indicates the command is found but is not executable.

    Is this service running under your user context? Generally when I am building a system service I put it under /etc/systemd/system and it runs as root without issues unless I specify.

    • Telorand@reddthat.comOP
      1·
      3 days ago

      The service is in that folder, but it’s not automatically assuming to run as root. Maybe it’s an SELinux thing, since this is on Bazzite…?

      Either way, I tried adding

      [Service]
User=root
Group=root
ExecStart=...

      And it’s still throwing that 126. It’s definitely executable, but maybe it’s not a bash script, though I dunno what else you’d use to run it. To manually start it, you just type sudo /path/to/daemon (no file extension).

      Edit: definitely not a bash script. Kate can’t read it. It looks like it’s some kind of pre-compiled binary.

      • intensely_human@lemm.ee
        1·
        2 days ago

        Does the service include execute permission for the root user or group? Unsure if root user or group can be blocked from permissions or not, but do you have chmod +x and the service is owned by root and/or the x is in the “everyone” place?

        • Telorand@reddthat.comOP
          1·
          2 days ago

          Root is required, but it’s already an executable binary, not a script. chmod +x and chmod 755 both had no effect on the 126.

          Fortunately, it was solved by adding /usr/bin/env to the ExecStart line. According to another user, the default environment is limited, so the script was probably looking for some specific environment variables, which env can provide.

          Normally, this would be set up by default with the installation script, but I’m trying to set this up on Bazzite, so there’s some problematic issues to overcome.

  • bushvin@lemmy.world
    3·
    2 days ago

    Why use /bin/bash in your ExecStart directive? You can just specify the path to your daemon.

    /bin/bash expects a script, not a binary, which your daemon most probably is…

    • Telorand@reddthat.comOP
      1·
      2 days ago

      Nope, leaving off the initial env call, in this corrected case, gives a 203/EXEC error.

      It would have been easy if I could just call the binary, but alas. Dunno why, but there it is.

      ETA: this is on Bazzite, so maybe systemctl behaves slightly differently…?

        • Telorand@reddthat.comOP
          1·
          2 days ago

          Nope. sudo /path/to/daemon works. Thankfully, the service launches, now that I’ve included /usr/bin/env.

          It would have been nice if it was an easy to read script, to tell what it needed, but alas.