systemd: Is it wrong?

[Lennart Poettering]

On Sun, 10.07.11 20:49, Steve Dickson (SteveD at redhat.com) wrote:

> >> So basically what you are saying is a service can never consist of 
> >> more than one system daemon. 
> > 
> > Well, it can, but we encourage you not to do this.
> > 
> > The word "service" is mostly used synonymously with "daemon" in the
> > systemd context, and we prefer if people write one service file for each
> > daemon, as this is the easiest to understand for admins and users and
> > makes sure supervision/monitoring works properly.
>
> Ok.. Now understand where my confusion is... Currently when one
> want to start the nfs server they type 'service nfs start' which
> calls a number of binaries and ultimately a system daemon.
> 
> Now if they enable want secure nfs, they edit a file in /etc/systconf
> and simply type 'service nfs restart' which again runs a number 
> of binaries and start a couple of system daemons.
> 
> My point it this. You are changing the meaning of 'service'. People 
> expect a service to be just that as service. When one starts a 
> service all the needed daemons are started and all the configuration 
> is done once the service is started.

I think most people actually expected that one service file would start
one service.

> Unless I'm misunderstanding, for an admin to the same thing as above 
> the will have to type of string of commands enabling all the needed
> daemons... People are not expecting or even what to know which daemon 
> is need to start up each service... oops.. a service is not longer
> as service its a daemon... hmm... let use subsystem... see my point?

No I don't.

Note that you can have dependencies between services: you can say that
when service A is started service B must be started too and finished
before A. These are *runtime* dependencies. You can also say that when A
is enabled B should be enabled too. These are *install time*
dependencies. The former are suppoirted via Wants= and Requires= in the
[Unit] section, then latter in via Also= in the [Install] section of
unit files.

> >> Maybe a better way to says is ExecStartPre= should not be used for 
> >> daemon process? 
> > 
> > Well, technically, not only daemon processes do this, but that's
> > nitpicking, so let's not discuss this part further.
> Right.. Not only daemon processes spawn off processes that fork and stay in the
> background. How are we suppose to know if he flux capacitor command will or 
> will leave a process background? 

Hopefully the folks writing a unit file know the software they are
writing it for. It is our intention after all to get these unit files
shipped upstream, i.e. they are written by the upstream developers.

> > Simplify things, have as many levels of disabling as necessary but as
> > few as possible, and unify that across the different services. This is
> > what we want to ensure by getting people to use "systemctl enable"
> > instead of having service-specific sysconfig files for
> > disabling/enabling services.
>
> Hang on... you say that 'systemctl enable' will also configure a daemon
> like the sysconfig files do? Could you please give me an example of this 
> this?

No, this is about enabling/disabling daemons. systemctl enable/disable
is not about configuring arbitrary parameters to daemons.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.