systemd (was Re: Gentoo guys starting a fork of udev)
Hi - please change the Subject: of the thread if the topic of conversation
has moved on. (We're all guilty of not doing this enough…)
On Wed, Nov 21, 2012 at 12:07:29AM -0600, Kevin Toppins wrote:
snip 32 line preamble
I realise your intentions are good, here, but please, it is not much help.
Writing concise and to-the-point messages is the best way to communicate
on a list like this.
> Please don't answer with a reference to read some kind of
> documentation.
Sadly it is obvious from the rest of this message that you are not up
to speed on the topic here. If you want to usefully contribute to the
topic, at a very least you should familiarise yourself with the prior
threads about systemd to debian-devel. At a very, bare-minimum least.
It would then of course be polite to other thread participants to make
sure you are at least up to speed on what systemd is and how it works…
> I think it is categorically important to *identify* and *convey to the
> community*...
>
> -> What role is systemd designed to facilitate?
> -> Do we know why we want to prevent a process from forking?
This is something that pretty much goes without saying, if you are
familiar with the technology which underpins what we're talking about.
> -> Let's hypothetically decide to prevent a fork on some conditional
> basis (as opposed to no forks at all).....is it systemd's
> responsibility, or would that fall to the responsibility of the linux
> kernel?
It's the init systems responsibility. Systemd's implementation relies on
a kernel feature to work (cgroups). The division of responsibility seems
very sensible here.
> -> If simply checking that the daemon's permissions were set
> correctly before execution would solve this problem, then it would
> make sense that a system redesign need not be in order.
It wouldn't. The UNIX permission model does not address this problem.
> -> Enforcing permissions is the responsibility of the linux kernel. Not
> systemd.
snip
> Why should this model be changed, and why should systemd enter into the
> authority architecture of the system?
It isn't being changed. Systemd uses a kernel feature (cgroups) to achieve
this. What you have written makes no sense. It's the kernel's job to
enforce traditional UNIX permissions, but you need userland software
like chmod to actually manipulate them.
> -> Establishing and maintaining the permissions is the responsibility
snip
> -> POSIX capabilities is already in place to prevent/hamper runaway
snip
These questions are based on your flawed understanding of the relationship
between the kernel, systemd and cgroups, my reply above essentially covers
these.
> Well what if some modifications to the init scripts where made
> something along the lines of....
snip, and
> Why not just modify _autofs_ to check upon startup....
Here we go. You're saying "I acknowledge feature X as useful. Instead of
moving from existing software A, lacking feature X, to existing software B with
feature X, let's alter software A to incorporate feature X".
Oddly enough the authors of systemd decided against that route, as did the
authors of upstart. It is no good us arguing hypotheticals. You or anyone else
who favours this approach, go away and actually implement this stuff in
sysvinit, and then when you can show that it works, we can debate along these
lines. But I tell you, the upstart and systemd authors are not idiots. Nor the
openrc people, nor the authors of a half-dozen other init replacements. If
this was a feasible way forward, perhaps one of these enlightened engineers
would have done it? In all honesty the one thing I don't think is up for
debate anymore is that sysvinit needs to be replaced if we are to benefit from
these newer features.
> And more importantly..... why should systemd be involved in this? What
> does systemd do that the daemon's launch routine cannot accommodate?
You need to read up on what systemd does.
> Why should systemd be involved in this? Not everybody has a need for
> autofs, likewise, not everybody should need systemd to handle a
> problem with autofs for autofs/them.
You're half baked suggestions for sysvinit and autofs are the first steps
on the road to writing systemd again. What's becoming clearer and clearer
in your message is that what you object to in systemd is not what it does
or how it does it (which you don't understand) but simply the name itself.
You are a victim of the anti-hype.
> First.... the data in the volume won't be available until the fsck
> completes, so the server won't be able to give the data any faster
> than it takes to fsck the volume. Minimum time limit, unless you have
> a new filesystem check design to get around this, that is a rather
> unchangeable wait time until you can *serve* the data.... You might
> investigate why fsck takes the time it does and how could fsck be made
> faster.
Having the server up even if the data partition is not ready yet can be
useful in many situations. Not least aiding debugging if the fsck fails,
difficult if you are forced to do it over a serial console or other
form of remote console. Many people run multiple services from one
physical system.
> Would this not work just as well....
No. And it's so patently obvious it wouldn't that pointing out *why* not
is an exercise in frustration. It's not the job of -devel to educate
drive by commenters on the features of the software they choose to throw
their opinion in on ☹
> It seems many lines have been blurred and I am trying to bring them
> back in to focus.
They seem blurred *to you* because you are not up to speed on what these
thing do and how they do them. It's in the eye of the beholder.
Reply to: