On Thu, 14 Apr 2011 15:28:28 +0200 Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Thu, 14.04.11 12:55, Michal Hlavinka (mhlavink@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
