systemd: Is it wrong?

[Steve Dickson]

On 07/08/2011 10:57 AM, Lennart Poettering wrote:
> On Fri, 08.07.11 09:57, Steve Dickson (SteveD at redhat.com) wrote:
> 
>>> I am pretty sure systemd-devel is the better place to discuss this. But
>>> here are a few comments after reading throught the bug report:
>> I didn't know it existed... 
> 
> That would have been the first big free software project without any
> mailing list, wouldn't it?
Point! :-)

> 
>>> Yes, we want that people place each service in an individual service
>>> file. Only then we can supervise the services properly. It is possible
>>> to spawn multiple high-level processes from a single service, but that
>>> is mostly intended as compat kludge to support SysV init scripts where
>>> this is possible. In general however, we want people to do have a 1:1
>>> mapping. Only then we can restart services if needed, we can catch
>>> crashes, and show proper information about your service.
>>>
>>> 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. 

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

> 
>>> ExecStartPre= is executed strictly in order, and in the order they
>>> appear in the unit file.
>>
>> True, but there is no synchronization. Meaning first process can 
>> end after the second process, which think is a problem.
> 
> 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 believe that services should be enabled/disabled at one place only,
>>> and that is where you can use "systemctl enable" and "systemctl
>>> disable". Adding a service-specific second-level of disabling in
>>> /etc/sysconfig/ is confusing to the user, and not necessary. You'll do a
>>> great service to your users if they can enable/disable all individual
>>> services the same way. (And UI writers will be thankful for that
>>> too)
>>
>> In a simple subsystem maybe, but many subsystems have a large number
>> of configuration knobs that are needed so the subsystem can function
>> in a large number of different environments. So in the past its
>> been very handy and straightforward to be able to tweak one file
>> to set configurations on different, but related, subsystems. 
> 
> 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...
 
> 
>>> This is not going to work:
>>>
>>> ExecStart=$FOO bar waldo
>>>
>>> I.e. variable substitution for the binary path (it will work for the
>>> arguments, just not for the binary path). This limitation is necessary
>>> due to some SELinux innerworkings in systemd. It's a limitation we
>>> probably could fix if we wanted to, but tbh I find it quite questionable
>>> if you spawn two completely different binaries and still call it by the
>>> same service file.
>>
>> Spawning different binaries to do set up, like exporting directories 
>> before the a system daemon is started seems very reasonable and expected
>> practice.
> 
> Hmm? You can start as many binaries in ExecStartPre= as you wish, one
> after the other, but we don't support that you can change the path of
> them dynamically with an env var. env vars are only expanded for
> arguments, not for the binary path itself.
Ok... I did misunderstand what you were saying... 

> 
>>> In general if services use a lot of /etc/sysconfig/ settings then this
>>> is probably an indication that the service code should be fixed and
>>> should just get proper configuration files. 
>>
>> I don't understand this generalization. For a very long time subsystems 
>> have used /etc/sysconfig to store there configuration files and now they
>> are broken because they do? Plus they are not "proper" configuration
>> files?
> 
> People have done lots of things for a long time, that doesn't make it
> the most elegant, best and simplest solution.
> 
> 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... 

That is your opinion which may or may not be held by the rest
of community... So please recognize it as such and please 
be willing to accept dissenting views.... 

steved.