|
Michael Biebl:
Please do not. It is an erroneous conclusion based upon a faulty
analysis that conflates the readiness
protocols with the
non-daemon nature of the way that things are run by the The correct approach follows this maxim: If the many years of pressure have led to a program having a way to run under daemontools, and that is even documented right there in the program's manual page, then that is also very likely the best way to run it under systemd, too. The requirements that the systemd people put forward for what they naïvely call "new-style dæmons" are in fact the same behaviours that the daemontools world has lobbied for for the past couple of decades (and has fairly widely succeeded in obtaining over that time), and that IBM was setting out fast approaching a quarter of a century ago. * http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html That is the case here, using the daemontools mode is how to
address this problem, and the original service unit file (in --- systemd.service.original 2018-02-07 19:44:24.000000000 +0000 +++ systemd.service 2018-02-07 19:58:36.307113285 +0000 @@ -6,8 +6,10 @@ After=network.target [Service] -Type=forking -PIDFile=/run/dnsmasq/dnsmasq.pid +Type=simple +RuntimeDirectory=dnsmasq +RuntimeDirectoryMode=0755 +ExecStartPre=/bin/chown dnsmasq:nogroup %t/dnsmasq # Test the config file and refuse starting if it is not valid. --- init.original 2018-02-07 19:44:24.000000000 +0000 +++ init 2018-02-07 20:06:25.215113285 +0000 @@ -292,13 +292,8 @@ stop_resolvconf ;; systemd-exec) -# /run may be volatile, so we need to ensure that - # /run/dnsmasq exists here as well as in postinst - if [ ! -d /run/dnsmasq ]; then - mkdir /run/dnsmasq || return 2 - chown dnsmasq:nogroup /run/dnsmasq || return 2 - fi - exec $DAEMON -x /run/dnsmasq/$NAME.pid \ + # systemd's mechanisms handle the runtime directory. + exec $DAEMON --keep-in-foreground \ ${MAILHOSTNAME:+ -m $MAILHOSTNAME} \ ${MAILTARGET:+ -t $MAILTARGET} \ ${DNSMASQ_USER:+ -u $DNSMASQ_USER} \ |