how to start svnserve with systemctl systemd

Question

subversion package in debian jessie does not include a systemd service file. what is the simplest solution for automatic start. i try

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
#EnvironmentFile=/etc/conf.d/svnserve
#ExecStart=/usr/bin/svnserve --daemon $SVNSERVE_ARGS
ExecStart=/usr/bin/svnserve -d -r /svnFolder/repositories
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=svnserve.service

it is an adaptation of https://bbs.archlinux.org/viewtopic.php?id=190127 but i have put the arguments directly for svnserve directly here.

what can be improved?

Solution 1

Here is a proposal to setup svnserve service "the-Debian-way" running with a dedicated svn service account with proper logging. According to FHS, repositories should be stored in /srv/:

mkdir -p /srv/svn/repos; chown svn /srv/svn/repos

First, the service configuration for systemd /etc/systemd/system/svnserve.service:

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
RuntimeDirectory=svnserve
PIDFile=/run/svnserve/svnserve.pid
EnvironmentFile=/etc/default/svnserve
ExecStart=/usr/bin/svnserve $DAEMON_ARGS
User=svn
Group=svn
KillMode=control-group
Restart=on-failure

[Install]
WantedBy=multi-user.target

Second, the service startup options at /etc/default/svnserve:

# svnserve options
DAEMON_ARGS="--daemon --pid-file /run/svnserve/svnserve.pid --root /srv/svn/repos --log-file /var/log/svnserve/svnserve.log"

To work properly, the folder for log files must be created with proper ownership and run location for pid file too:

mkdir /var/log/svnserve; chown svn /var/log/svnserve
mkdir -p /run/svnserve; chown svn /run/svnserve

To end with log rotation configuration /etc/logrotate.d/svnserve:

/var/log/svnserve/*.log {
    daily
    missingok
    rotate 14
    compress
    notifempty
    create 640 svn adm
    sharedscripts
    postrotate
            if /bin/systemctl status svnserve > /dev/null ; then \
                /bin/systemctl restart svnserve > /dev/null; \
            fi;
    endscript
}

Hope this helps.

Solution 2

Update: My answer below has been obsoleted. These improvements and others have been incorporated into Yves Martin's excellent solution.

I have two improvements: it's generally recommended not to run such things as root. Create a user for this, for example 'svn'. It is also recommended to explicitly specify a PID file when using forking. My svnserve.service looks much like yours except I add the lines:

User=svn
Group=svn
PIDFile=/usr/local/svn/svnserve.pid
ExecStart=/usr/bin/svnserve  -d -r /usr/local/svn/repos --pid-file /usr/local/svn/svnserve.pid

Solution 3

One comment on Yves Martin's excellent answer above (I don't have the rep points to comment yet):

When trying to enable the service to start on boot, I'd get an error:

$ sudo systemctl enable svnserve.service
Failed to execute operation: Invalid argument

After doing some research I found you apparently cannot set an alias to the same name as the service. Deleting the Alias line from the [Install] section of the svnserve.service solved the issue:

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
RuntimeDirectory=svnserve
PIDFile=/run/svnserve/svnserve.pid
EnvironmentFile=/etc/default/svnserve
ExecStart=/usr/bin/svnserve $DAEMON_ARGS
User=svn
Group=svn
KillMode=control-group
Restart=on-failure

[Install]
WantedBy=multi-user.target

Comments

[user855443]

A PID FILE is looks like a good idea as does the separate user. thank you!

[EricS]

I've changed this to put the pid file in a directory fully managed by the svn user rather than /var/run/svnserve. /var/run was temporary on the system I was using. Perhaps it would be better to have a startup script create and permission /var/run/svnserve but I chose not to deal with it. Perhaps someone else can improve this.

[Grexis]

@Yves Martin Thanks for this solution. I recently used a variation of this solution and had a few comments. First off, in /etc/default/svnserve, the arg flag for the log file should be --log-file, not --log. Also, while creating the log directory only needs to be done once, /var/run is not guaranteed to persist. It would be better to use the RuntimeDirectory= directive. In Ubuntu, /var/run is a symlink to /run.

[Grexis]

@EricS I had the same issue. The RuntimeDirectory= directive is perfect for this, and there is tmpfiles.d for anything more complicated.

[Yves Martin]

@Grexis Many thanks for your improvements. This service setup looks great now. I learned yet another feature of systemd and fix my FHS about /run. Thank you

[K Richard Pixley]

Won't this break outstanding svn connections during the logrotation? That is, if I'm in the middle of an svn operation, say, a long checkout on an automated builder, won't the "restart" interrupt and thus break my svn connection and thus my build?

[Yves Martin]

Good question. As far as I know, svnserve forks for each request and waits for child to stop before exiting... so I think there is no chance to cancel an in-progress operation

[Yves Martin]

I reverted KillMode to default control-group or else child processes are left running. ExecReload does not have expected effect, process is simply killed.

[Mac]

semanage add option requires two '-', as in: # sudo semanage fcontext --add --type svnserve_content_t "/project/svn(/.*)?"

[Zhilong Jia]

It seems sudo mkdir -p /srv/svn/repos is necessay before editing /etc/default/svnserve if there is no this dir, /srv/svn/repos.

[Admin]

Thanks @Mac. Fixed

[EricS]

I'd like to draw attention to an answer below by @Matt Hovey that suggests removing the alias line. I too find that having this line prevents the systemctl enable command from working (on Ubuntu 20.04).

[EricS]

I find this to be true also, on Ubuntu 20.04. I get a different error from enable though: "Failed to enable unit: File /etc/systemd/system/svnserve.service already exists." Thanks for this!

[Possum]

The combination of User=... + PIDFile=/run/... wasn't working for me (on RHEL7), because user svn can't write to /run/.... Even with a svn user owned subdirectory, the subdirectory was getting wiped out. I got this to work by ditching the PID file and using GuessMainPID=true.

[Yves Martin]

RHEL cleans /run at boot, whereas Debian does not. It may be interesting to find a portable way to write non-root PID file from systemd service.