Systemd unit file implementation questions (ypbind)

[Simo Sorce]

On Thu, 14 Apr 2011 15:28:28 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Thu, 14.04.11 12:55, Michal Hlavinka (mhlavink at redhat.com) wrote:
> 
> > 
> > On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote:
> > > 
> > > > Is there a good solution for this?
> > > 
> > > Which service ( file ) is this.
> > > 
> > > I can take a look at to see which way is best to approach it.
> > 
> > It's package nut : /etc/init.d/ups, there are 3 services: driver,
> > upsd and upsmon. All three services usually run on the same
> > machine, but it's not the only use case. There is going to be
> > slight change for yet another use case. Better not to get inspired
> > by init script, but think about situation where there are three
> > services and some/all of them should be started based on variable
> > in config file (so existing configuration works).
> 
> I think it is a good idea to enable/disable services only at once
> place, the init system, instead of adding additional per-service
> layers of disabling. An admin should not have to know how each
> service is specifically configured in detail just to enable or
> disable it.

While this make sense in abstract, it may fall short when it comes to
specific cases.

It really comes down to defining "service".
For an admin "service" is generally a (set of) program(s) that performs
a function. Whether the service requires one or three daemons is
generally not really interesting for the admin unless he wants to dig
the details.

In particular having to know which of three daemons to enable given a
specific configuration is burdensome, as the admin now have to learn
which one is required depending on the configuration. For some services
this may be straightforward, for others not. And being forced to learn
that is not really nice, esp. if it was not necessary before.

It is particularly obnoxious if you have to remember to change a
different configuration (the init system) if you are just changing your
service configuration.

> That means: if the admin enabels a service in systemd, the startup
> script should not refuse starting just because it is disabled in
> another config layer. That would be very confusing.

And yet the contrary is also true, see above.

Systemd needs to offer a way to handle these situation until most
distributions decide to adopt systemd. Because upstream has to deal
primarily with sysvinit, and many will not care about systemd until it
is widespread.
You cannot expect package maintainers to heavily patch software and
even change how it behaves or how it is configured just because Fedora
decided to use systemd.

Where it is possible to easily switch to systmed, I am all for
providing specific configuration and adaptation, but systemd needs to
cater for the needs of software that is developed primarily on sysvinit
based systems.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York