Re: systemd: Is it wrong?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 08.07.11 09:57, Steve Dickson (SteveD@xxxxxxxxxx) 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?

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

> > 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=".

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

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

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

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux