systemd: Is it wrong?

[Steve Dickson]

On 07/10/2011 06:47 PM, Lennart Poettering wrote:
> On Sat, 09.07.11 23:32, Steve Dickson (SteveD at redhat.com) wrote:
> 
>>>>> So, I'd suggest strongly not to try starting all services from a single
>>>>> file. There's a reason why we explicitly forbid having more than one
>>>>> ExecStart= in a unit file (except for Type=oneshot services).
>>>>
>>>> Thank you for this explanation. It appears your definition of a
>>>> service might be a bit too simple for many subsystems. You seem
>>>> to think that on service will only start one system daemon, which
>>>> is not the case in the more complex subsystems. 
>>>
>>> Well, I doubt about the "many". In fact, I am aware of only one other
>>> occasion where people were wondering about this. And often the problems
>>> are only perceived problems, because people try to translate their sysv
>>> scripts 1:1 and are unwilling to normalize their scripts while doing
>>> so.
>>
>> 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.

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?
 
> 
>>>>> Also, you should not spawn forking processes in ExecStartPre=, that's
>>>>> not what it is for. In fact I am pretty sure I will change systemd now
>>>>> to kill off all remaining processes after each ExecStartPre= command now
>>>>> that I am aware that people are misusing it like this.
>>>>
>>>> If they are not for forking off process, what are the for? It seems
>>>> quite logical that one would use a number of ExecStartPre= commands
>>>> to do some set up and then use the ExecStart= to start the daemon.
>>>
>>> This is a misunderstanding. What I tried to say is that they should not
>>> be used to spawn off processes that fork and stay in the
>>> background. Processes in ExecStartPre= are executed synchronously: we
>>> wait for them to finish before we start the next one, and they should
>>> not try to play games with that and spawn stuff in the
>>> background. That's what I meant by saying "you should not spawn
>>> *forking* processes in ExecStartPre=".
>>
>> 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? 

> 
>>> There is synchronization. As I made clear a couple of times, we never
>>> start more than one ExecStartPre= process at a time. We start the next
>>> one only after the previous one finished.
>> Looking at https://bugzilla.redhat.com/show_bug.cgi?id=699040#c35 appears
>> this is not the case... 
> 
> I think this is a misunderstanding. "systemctl show foo.service" will show you the
> actual timestamps when we started/joined a process.
Fine... I didn't know about the show command... 

> 
>>> Well, nothing stops you from reading the same configuration file from
>>> multiple services. We do that all the time, for example for
>>> /etc/resolv.conf.
>>
>> True... but the point is before systemd, an admin could tweak one
>> /etc/sysconfig file which define which daemon were started and 
>> how they were configured... Unless I'm missing something that 
>> is no longer the case... The admin will have to explicitly define
>> each an every daemon they need to run and how they are configured..
>> all by hand...
> 
> Well, I think it is much easier for admins if services can be
> enabled/disabled all the same way, instead of adding arbitrary numbers
> of service-specific ways to enable/disable them.
They have that today... its call the chkconfig which enables/disables
services... not just daemons.

> 
> 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?

> 
>>> By proper configuration files I mean configuration files read by the
>>> daemons themselves, instead of files that are actually a script that is
>>> interpreted by a programming language and some more scripts intrefacing
>>> with that.
>>>
>>> Or in other words: configuration via command line arguments or
>>> environment variables sucks. Much nicer are proper configuration
>>> files. And faking config files by parsing them in shell and then passing
>>> them of to daemons via env vars and cmdline args is not ideal.
>                                                      ^^^^^^^^^^^^
>> So basically what you are is the way system daemon have been
>> started for the last.. say...  twenty years or so is completely 
>> wrong and systemd is here to change that! 8-) The point being... 
> 
> I used the word "not ideal", not "completely wrong". Amazing that you
> can misquote me like this even though these were the last three words
> of the paragraph you are responding to here! 
My apologies for misquoting you... I did indeed miss the "not ideal" part.


steved.