[Nut-upsdev] RFC: nut and systemd

Michal Hlavinka mhlavink at redhat.com
Mon Apr 18 14:36:45 UTC 2011


you've probably heard about systemd already. In Fedora 15, it's 
used as default instead old SysV init system. While there is some
backward compatibility layer, everything is going to be ported from
/etc/init.d/<something> init scripts to systemd's service files 

Unfortunately?, systemd is not 1:1 compatible with old init scripts.
Now (at least in Fedora) we have /etc/init.d/ups init script which 
starts a)upsdrvctl, upsd, upsmon OR b)just upsmon - that based on 
value in /etc/sysconfig/ups. (btw, I've got complaint recently that in
 "server" mode it should be possible to start just upsdrvctl and upsd, 
without upsmon.) 

systemd "prefers" daemon per service/unit file, so it's not possible 
to have the same functionality as is with init script.

1) systemd does not support:
source /etc/sysconfig/ups
if [ "$SERVER" = yes ]; then

because it has it's special syntax.

2) it does not support:
ExecStart=[ "$SERVER" != yes ] || /sbin/upsdrvctl
ExecStart=[ "$SERVER" != yes ] || /.../upsd

because it does not use shell

3) it "somehow" supports
and put shell script code from #1 there and handle other stuff myself. 

This is somehow ugly solution and despite it is supported, systemd does 
not like it (it prefers one not-background-forked daemon per service 
file, so it can monitor & other stuff thanks pid of the daemon is pid of 
executed process). But - this is only way how to make nut work the 
same way as old version. So the question is if it's worth it from long time pov.

4)The systemd's way:
- 3 service files
- one for upsd and one for upsmon. This means SERVER configuration 
from /etc/sysconfig/ups goes away. 
- two services configured by user (ups.service/nut.service=upsd, nut-monitor.service=upsmon) 
- upsdrvctl as on demand service (started before upsd, stoped after upsd)

So, the question is: 3) or 4) ?


More information about the Nut-upsdev mailing list