[Nut-upsdev] RFC: nut and systemd

[Michal Hlavinka]

> as a first note, I just want to remember you the existance of
> $(sysconfdir)/nut.conf, to replace both Debian's /etc/default/nut and RedHat
> /etc/sysconfig/ups.

afaik this is not compatible to "4)" For this, upsmon must me separated, so you'd get
something like
/etc/init.d/nut (for upsdrvctl and upsd)
/etc/init.d/nut-monitor (for upsmon)

 
> 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
> > /lib/systemd/system/<something>.service
> >
> > 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.)
> >
> 
> I'm interested in users feedback here (mostly for my own info):
> are they using PDUs, or only supervising UPSs?

there is user experience with systemd and any ups daemon, 
afaik Fedora has only 2 of them (nut and apcupsd). And it'll be my task to 
modify apcupsd to use systemd.
 
> the MODE in nut.conf is meant to be extended.
> I once evoked a "upower" mode (drivers started by udev) and a "manual" one
> (started by whatever other mechanism that only need pieces of NUT).
> 
> 
> > systemd "prefers" daemon per service/unit file, so it's not possible
> > to have the same functionality as is with init script.
> >
> 
> can you please point us some sample scripts for equivalent services?

a)equivalent services=ups daemon, there is no such example (yet). nut 
was chosen to be the first one

b)equivalent services=more daemons started by one init script - I'm not 
aware of anything like that. Usually such services have one master process
reading configuration and starting what is needed.

c)example of systemd service file:
============== smartd.service ==============
[Unit]
Description=Self Monitoring and Reporting Technology (SMART) Daemon
After=syslog.target

[Service]
EnvironmentFile=/etc/sysconfig/smartmontools
ExecStart=/usr/sbin/smartd -n $smartd_opts

[Install]
WantedBy=multi-user.target
==================================
it can read basic shell-like variables (/etc/sysconfig/smartmontools) 
and pass them to command line. It can't contain any conditional in 
service file
 
> > 1) systemd does not support:
> > source /etc/sysconfig/ups
> > if [ "$SERVER" = yes ]; then
> > /sbin/upsdrvctl...
> > /.../upsd
> > /.../upsmon
> > else
> > /.../upsmon
> > fi
> >
> > because it has it's special syntax.
> >
> > 2) it does not support:
> > ExecStart=[ "$SERVER" != yes ] || /sbin/upsdrvctl
> > ExecStart=[ "$SERVER" != yes ] || /.../upsd
> > ExecStart=/.../upsmon
> >
> > because it does not use shell
> >
> > 3) it "somehow" supports
> > ExecStart=/usr/libexec/nut/systemd_helper
> > 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) ?
> >
> 
> as Charles said, the 4th one is the obvious solution to *your* (or *systemd*
> if you prefer) issue.
> I'd like to see an example POC implementation of this, since details are
> still unclear to me (ex: what means an "on demand servive"? no .service
> file?).

For example dovecot (imap server) can be started on demand. systemd listens 
on port 143 and when there is incomming connection, it starts dovecot. On-demand 
service needs service file.

There is more on-demand events (device, another service,....)

Simple on-demand (required by different service file) should be suitable for upsdrvctl.
1) Create simplified nut-device.service (no [install] section...)
2) Create upsd service and add Requires=nut-device.service After=nut-device.service
so when you start upsd by hand or during boot process it starts upsdrvctl firts. If you 
add StopWhenUnneeded=yes to nut-device.service it stops upsdrvctl after stopping 
upsd service.