[Nut-upsdev] RFC: nut and systemd

[Michal Hlavinka]

On Thursday, May 12, 2011 09:26:38 Arnaud Quette wrote:
> Hi Michal,
> 
> first, I know understand where our "disagreement" comes from:
> in Debian, we have a generic ups-monitor role provided by several packages.
> the shutoff (final ups poweroff) hook is located in the package's
> initscript, and is called from halt.
> whereas, in RH/Fedora, you don't have this generic role (afaik), nor the
> hook in the package's initscript.

in Fedora 14 (and older) the hook is in /etc/init.d/halt initscript. This no 
longer exists in Fedora 15+. I've asked systemd maintainer if they ported this 
hook from old initscript to systemd, because I was not able to find it.

> which means that NUT initscript in RH only has to deal with
> start/stop/restart, which are the standard conditions.
> I'll have to think more about that, but for the time being, you may want to
> progress with your previously mentioned approach (4).

I'm already working on it. I'll send it to the list, when it's ready, but just 
right now it's blocked by bug in systemd.

Because we've missed Fedora 15 deadline, we have some time right now (but the 
sooner it gets in rawhide for testing the better). nut will use compat layer 
of systemd in Fedora 15 (sysv -> systemd service files changes in 
released/frozen versions are forbidden)

> > > you've completely missed my invitation to talk about packaging
> > > standardization:
> > > was it intentional?
> > 
> > nope. AFAIK packaging is already standardized on all distributions,
> 
> I don't think we're talking about the same things!

seems differences are bigger than I thought...

> Here are the packages on Suse (@Stan: nothing missing?)
> - nut (provided by either nut-classic or nut-hal iirc)
> - nut-cgi
> - nut-classic
> - nut-devel
> - nut-drivers-net
> - nut-hal
> - libupsclient1
> 
> On RH/Fedora:
> - nut
> - nut-cgi
> - nut-client
> - nut-devel
> - nut-hal
> - nut-xml

We've removed nut-hal from Fedora 16+, because hal was removed completely.

> 
> Here are the one on Debian and its derivatives:
> - nut
> - nut-cgi

> - nut-hal-drivers
we won't have this one

> - nut-powerman-pdu
> - nut-snmp
> - nut-xml

no problem with these. Just I'm not sure whether powerman really requires 
extra package?

> - libupsclient1
> - libupsclient1-dev

packaging policy in Fedora would preffer nut-lib or something like that

> On Debian, several new packages will appears:
> - nut-doc (+ nut-doc-html and nut-doc-pdf)
this change is fine

> - nut-client (for moving upsmon and base clients)
we already have this one

...
> > system little bit different. I don't think nut&systemd configuration
> > must
> > be the same as nut&SysV or nut&upstart, it just seems that systemd is
> > going to be adopted by other distributions (definitely not by all of
> > them), so I'd like to standardize nut&systemd the way which does not
> > need to be 100 % compatible with SysV init system (at least from my
> > POV).
> 
> AFAICT, sysV init and upstart can work with MODE (and "external" settings).
> systemd seems to have a more simple approach, that doesn't allow condition,
> nor external settings, nor any other hook than start/stop/restart.
> do you know if there any plan for such non standard actions/hooks for
> systemd?

I'm not sure about this, I've asked systemd maintainer

> 
> > > - simplicity: you set one "var", instead of 2 in you system.
> > 
> > afaik for upsdrvctl, upsd and upsmon the first two should work together
> > always and the third one is independent. So there are two "groups"
> > A=upsdrvctl&upsd  and B=upsmon
> 
> indeed. which doesn't implies to have 2 configuration files.
> 
> change from:
> > chkconfig ups on
> > to
> > systemctl enable ups.service
> > or
> > systemctl enable ups.service; systemctl enable upsmon.service
> > 
> > does not make that big difference and I think this behavior is
> > expected (at least in Fedora/RHEL).
> 
> just ask yourself the question:
> do users want to know that they need to start upsdrvctl / upsd / upsmon?
> and the way they have to do it on every different system they might have.

Well I don't think it's that difficult. You can't survive in any distro if you 
don't learn administration basics and turning service on/off belongs in basic 
skill. I agree some nice gui/tui for nut would be great, but especialy because 
of files in /etc/ups/ not exactly because of initscripts+/etc/sysconfig/ups - 
or- systemd. I'm not against it, I'm fine with it. Just I don't see any benefit 
in replacing two or three simple basic commands with one different command for 
selection which service should (not) be started.

> or do they want to select a use case that matches their needs, like:
> - [manual and none] special cases,
> - standalone setup
> - network server (master),
> - network client (slave),
> - supervision (only implies driver(s) + upsd)

for these there is only ups-daemon and ups-monitor, so not that difficult choice

> - pm (power management ; only implies driver(s) in pm-mode, feeding upower,
> + upsd)

this can work without any changes (service de/activation), because dbus/socket 
activation can be used here

> > basically should it stop running service? restart only running? start
> > missing? Or simply should it ignore systemd's configuration or should it
> > ignore MODE= ? Whatever way it would be, it'd require some ugly hacks
> > and script wrapper around executables or auto modification of service
> > files (what if user changed anything in service file, should we touch
> > that file and break his configuration or ignore MODE=?). It seems to me
> > doing it the same way as other services on specific system/distribution
> > to be better way than trying to have systemd compatible with
> > sysv/upstart. Anyway, it's not expected that user changes his init
> > systemd as simple update process, but only on system upgrade OR it'll
> > require some manual changes.
> 
> well, were talking about an exception case here.
> services registration / activation is a point.
> what we are talking about, once more, is what is done inside of these
> scripts.
> 
> As an obvious (and probably the most basic) example with NUT:
> how will you handle the "poweroff" target of the NUT sysV init script?
> 
>       if upsmon -K >/dev/null 2>&1 ; then
>         if upsdrvctl shutdown ; then

I've asked systemd maintainer (he maintains also systemd's halt/rebot/... unit 
files - sysv's alternatives) about this (if they ported this functionality from 
old init scripts to systemd).