How can systemd run a command as root before launching a service as a different user?

fedora service svnserve systemd

19,030

The subversion package in Fedora is using systemd's tmpfiles mechanism to create /run/svnserve at boot with root ownership (since the packaged .service file apparently runs the daemon as root). You could copy /usr/lib/tmpfiles.d/svnserve.conf to /etc/tmpfiles.d/svnserve.conf and change the owner. See man tmpfiles.d for details.

19,030

DNS

Updated on September 18, 2022

Comments

DNS over 1 year
I'm running svnserve on a Fedora 17 machine with the following systemd service file:
```
[Unit]
Description=Subversion Server
After=syslog.target network.target

[Service]
User=svn
Type=forking
Environment=HOME=/repos/svn
ExecStart=/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid -r /repos/svn
PIDFile=/run/svnserve/svnserve.pid

[Install]
WantedBy=multi-user.target
```
This works fine as long as /var/run/svnserve is owned by svn:svn, but breaks on reboot when that ownership is reset to root:root. What I want is to add a pre-launch step that chowns the directory.

Unfortunately I can't find any real documentation on systemd unit files, but I saw that some were using 'ExecStartPre', so I tried this:
```
ExecStartPre=/bin/chown svn:svn /run/svnserve
```
Sadly this fails with an 'operation not permitted' error, so it looks like ExecStartPre also runs as the user specified in the unit file.

I also tried having the unit file run as root, then starting svnserve as the svn user via su, but that produced a vague error about the command-line being invalid.

How can systemd units perform actions as root prior to executing as a specific user?
- Michael Hampton about 11 years
  
  You report this as a bug. The permissions should already be correct on the /run directory and the pid file, but lots of these broke with the switch to systemd and the /usr move.
- DNS about 11 years
  
  @MichaelHampton I don't believe this is how it came out of the box. IIRC (this was set up a while back) svnserve doesn't come with a service wrapper, so this was something that we wrote ourselves.
- Michael Hampton about 11 years
  
  Subversion on Fedora certainly does come with this. It looks fairly similar to yours, though I would recommend you use the original. yum reinstall subversion
- Hauke Laging about 11 years
  
  If you gave your su command line we may be able to solve that problem.
- Charles Duffy about 7 years
  
  PermissionsStartOnly=false will cause all ExecStartPre and ExecStartPost commands to ignore User and run as root.
- neverhoodboy almost 6 years
  
  @CharlesDuffy I suppose you mean PermissionsStartOnly=true?
- Charles Duffy almost 6 years
  
  Err, right. Oops.
- starbeamrainbowlabs over 4 years
  
  I would disagree with the reason this question was closed. Although it's a about a specific systemd service, running a command as root before starting a systemd service is a common task (and I've found myself doing this more than once, @MichaelHampton.
- Michael Hampton over 4 years
  
  @starbeamrainbowlabs Hi, comments are not a good place for discussing these issues. You can visit Meta Server Fault and make a complete post for the community to see and discuss.
- starbeamrainbowlabs over 4 years
  
  @MichaelHampton Ah, I see. Not sure I'm confident about posting on a meta site though - I'm scared of doing it wrong :-/
- Michael Hampton over 4 years
  
  @starbeamrainbowlabs But you've already done it "wrong"! Posting on meta is the way to do it right.
- starbeamrainbowlabs over 4 years
  
  @MichaelHampton I've heard and seen many posts being flamed and downvoted on meta stack exchanges - even when the user clearly has good intentions.
- jbo5112 over 3 years
  
  "This question is unlikely to help any future visitors", except this in my exact question. Shouldn't obscure questions get answers too?
DNS about 11 years

Can't use sudo; there is no TTY when running systemd units.
Hauke Laging about 11 years

Why should sudo need a tty if no password is needed?
DNS about 11 years

I don't know exactly, but I had tried that idea, and the system logged an error stating that sudo requires a TTY.
Hauke Laging about 11 years

@DNS screen may be a solution in such cases.
Charles Duffy about 7 years

Whether sudo enforces a TTY is configurable in /etc/sudoers. Hackery such as screen is utterly inappropriate.
Davos over 6 years

@CharlesDuffy Thanks for pointing out that setting! But I read it the other way around, I run ExecStart as a specified User in the service file but want to run ExecStartPre as root so I should set this to true. "If true ... only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false." freedesktop.org/software/systemd/man/…
Charles Duffy over 6 years

@Davos, in that case, just use a preceding + for the ExecStartPre; ExecStartPre=+/path/to/thing-to-run-as-root; that way you're applying a change only to that one specific command, not making global modifications at all.
Davos over 6 years

@CharlesDuffy It's working without needing to do that. In the service file i have daemonuser as the user, whuch runs the ExecStart and PermissionStartOnly=true means that the ExecStartPre which creates a dir and chmods it runs successfully. I know it's working because daemonuser has no permissions on the mnt where the dir is created so it must be running as root, or have I missed something?
Charles Duffy over 6 years

nod -- the disadvantage of doing it that way is that any other Pre/Post commands added by dropins, generators, etc. are also impacted by the PermissionStartOnly; whereas a +-prefix is guaranteed localized.
Greg0ry about 4 years

@CharlesDuffy your comment is really an answer. Thanks for sharing!