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?

_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Reply via email to