Systemd, logrotate and PID-files

logrotatepidsystemd

I'm packaging some daemon for debian 8 and systemd.

The daemon can create PID-file by itself, but it has no permissions to write into /run because of non-root user. It used to create PID-file via old sysV init-script, but it doesn't work on systemd.

I can use workaround in service-file like this:

Environment="PIDDIR=/var/run/mydaemon"
PermissionsStartOnly=true
ExecStartPre=/bin/mkdir -p $PIDDIR
ExecStartPre=/bin/chown -R mydaemon. $PIDDIR

But it doesn't looks right.

I can use /tmp as $PIDDIR, but it also seems wrong.

Actually the only reason I need a PID-file is logrotate's postrotate sending SIGUSR1 to the daemon:

[ -s /run/mydaemon.pid ] && kill -USR1 `cat /run/mydaemon.pid`

It's also possible to search daemon's pid with pgrep, but it seems to be unreliable.

copytruncate in logrotate seems to be not the best option because of risc of loosing some part of log.

So, what is the right way to manage PID-files via systemd?

Аnd is there a way to sends random signals to daemons via systemd?

Best Answer

Systemd has dedicated mechanism to create temporary directories and files: systemd-tmpfiles and tmpdfiles.d

In short have your package drop a file /usr/lib/tmpfiles.d/mydaemon.conf :

 #Type Path            Mode UID      GID    Age Argument
 d     /run/mydaemon   0755 mydaemon daemon -   -

Related Solutions

Linux – Logrotate and Open Files

For those applications that don't accept the signals from logrotate as Rory described, I use a couple of methods.

Use the copytruncate option
Add a post-rotate statement to restart the service

The decision of which one to use depends on both size of log files and necessity of seamless logs. That's going to be a risk analysis on your own part. However, to give an example, I use a post-rotate restart on certain logs where I actually should be using a copytruncate. However, the files are often several gigs and the copy could take a long enough time that losing a second or two each night was preferable.

Nginx, logrotate and empty files

A bit late, but I've found it seems like its a bug in the USR1 signalling to nginx. According to the documentation it is meant to re-open the logs (http://wiki.nginx.org/LogRotation), but it doesn't appear to.

I've put a workaround in by sending a HUP instead, which will reload the configuration.

[ ! -f /tmp/nginx.pid ] || kill -HUP `cat /tmp/nginx.pid`

It appears to fix it, but if the USR1 call was working, it would be healthier to do that as its the minimal operation. HUP I don't think will drop any connections at least.

Related Topic