[Nut-upsdev] RFC: nut and systemd

[Charles Lepple]

On Apr 20, 2011, at 8:47 AM, Michal Hlavinka wrote:

> On Wednesday, April 20, 2011 08:22:53 Charles Lepple wrote:
>> 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).
>
> In systemd everything starts at the same time (if not explicitely set
> to wait for something), because systemd acts like xinetd so it creates
> all sockets,... and start some service when really needed and so on.  
> I'm
> not a systemd expert. In fact I don't miss any special functionality  
> and
> given I restart server only once per 2-3 months (kernel security  
> update)
> and using suspend on desktop, I don't care whether it boots 20 seconds
> or 2 minutes. In Fedora, there is a lot of people who like systemd  
> and a
> lot of people who hate it :)
>
>> I assume the following is the official home page?
>>
>>    http://www.freedesktop.org/wiki/Software/systemd
>
> yes
>
>>
>>> 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?
>
> Yes, one can use %post script in rpm for this. But what do you want to
> do there? With systemd (whether it's 3) or 4)) it works the same way
> as init script. After installation there is new service pre- 
> configured and
> off by default (Fedora packaging policy requires that daemons are not
> "on" by default after installation). There is no post-install  
> configuration
> right now. Usualy we try to pre-configure package to work out of the  
> box
> during rpm build process. If there is any gui/tui/cli tool for
> configuration we simply put it somewhere /usr/bin/ or /usr/share/..  
> or ...

I'm thinking of something more interactive than %post. I can respect  
the idea of starting with daemons off by default. However, if upsd,  
upsmon and upsdrvctl are separate, it could be nice to have a  
configuration tool which looks at nut.conf to see what combination of  
those three services should be started for a given NUT configuration.  
(For instance, starting upsd does not make sense without running  
upsdrvctl, but a monitor-only system would only start upsmon.)

...

>> That way, slower shell scripts
>> only execute once when the system administrator changes the
>> configuration, and systemd would read those generated files.
>
> Still the same question, what do you want/need that script for?

Maybe it's just a convenience that we don't really need. Arnaud?