Nut upsdev - Apr 2011 - RFC: nut and systemd

Hi,

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.) 

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
/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) ?

Cheers,
Michal

On Apr 18, 2011, at 10:36 AM, Michal Hlavinka wrote:
> Hi,
>
> 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
Haven't heard of it (still trying to wrap my brain around whatever  
makes upstart and launchd better than SysV or BSD-style init scripts).  
I assume the following is the official home page?

    http://www.freedesktop.org/wiki/Software/systemd
> 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) ?

Short answer: sounds like 4.

Arnaud probably has some thoughts about migrating from /etc/sysconfig/ 
ups to something a little more generic across distributions  
(nut.conf?), but if systemd doesn't use a shell to parse things (which  
is understandable for performance), is there a good point during  
package installation/configuration where shell scripts can be executed  
to dynamically generate the systemd configuration files?

In .deb-based systems, the package manager automatically configures  
the packages as they are installed. An administrator can also  
reconfigure later, and if debconf is set up correctly, this is where  
package installation and configuration scripts can query for  
configuration options.

I know that RPM has a number of pre- and post-installation scripts,  
but is there something for configuration that does not require re- 
installation to change configuration? That way, slower shell scripts  
only execute once when the system administrator changes the  
configuration, and systemd would read those generated files.

2011/4/18 Michal Hlavinka <mhlavink at redhat.com>
> Hi,
>
Hi Michal,

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.
The Debian init script has already started to use it for some versions:
http://git.debian.org/?p=collab-maint/nut.git;a=blob_plain;f=debian/nut.init;hb=HEAD

I would also like to link the below discussion linked to a broader
"packaging improvements" and NPS (NUT Packaging Standard [1]).
Thus I've cc'ed Stanislav, who may be interested in (I don't know
Suse
status on systemd / upstart / ...).
I know that some others will be interested in joining the discussion too.

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?

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?

> 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?).

I'm also seconding Charles' comments.

As told above, the way NUT binaries are currently distributed needs a
revamp.
And I'd like to finally see packagers / distributors seeting around the
table to discuss how to *cleanly* address that.

cheers,
Arnaud
--
[1] http://www.networkupstools.org/docs/packager-guide.chunked/index.html
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110421/8f202e66/attachment.htm>