Re: If Linux Is About Choice, Why Then ...
On Mon, Apr 10, 2017 at 10:37 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Sun, Apr 09, 2017 at 08:41:28AM +0100, Joe wrote:
>> Someone correct me if I'm wrong, but I run sid and see things come and
>> go. Didn't we have this:
>>
>> https://wiki.debian.org/LSBInitScripts
>>
>> long before systemd?
>
> This and start-stop-daemon and probably a few other things are all
> hacks that were layered on top of sysvinit, in an attempt to work around
> its limitations and produce some kind of management system.
That's one way of looking at it.
> Ultimately, all of these hacks are fragile and doomed to failure.
The kernel was once a fragile hack. People layered things on top of
it, people helped refactor it, ...
Linus stuck with it, in no small part because he was single and in a
situation where he could.
Fragile is not quite the argument it seems. There are other factors --
a small group willing to stick with it, the formation of a community,
...
(And the group in charge, although they need to be able to assert
themselves, doesn't need to decide it is the cabal.)
> The basic design concept of sysvinit is that you launch a daemon in
> the background and record its PID in a file on disk. Later, if you want
> to stop it, or see if it's still running, you open up this PID file,
> read the PID from it, and ask the kernel about the process with that ID.
sysvinit really never had an overarching design, but that could be
fixed with refactoring.
> Sounds OK, right? At least, if don't have much experience with system
> administration.
Heh heh
> The problem is, PIDs get recycled.
That's one of the things that could, erm, should get redesigned and refactored.
> If the daemon died 17 days ago, and
> something else came along and used that PID, the sysvinit approach of
> checking that the PID is still running will give the wrong result.
We need two sets of pids, system pids below 1024, maybe, but, no, set
the boundary at 2^16-1. Yeah, I'm saying we need to make pids 32 bits,
which will break things.
(Or, if we think of uptime in terms of years, maybe we need 64 bit
pids. But 16 bits is not enough.)
Or, maybe we need a process fingerprint in addition to the pid, if the
pid really can't be widened without making too much other stuff blow
up.
The non-system pid processes should be managed by something not pid 1,
which means that we may need to move traditional low pid processes
down in the list.
> Add to that the very real problem of the legacy behavior of daemons that
> originated in the 1980s: they double-fork themselves into the background,
> on purpose. This severs their tie to the parent process. That means
> you can't even *get* the PID of the actual daemon from the outside.
> The daemon itself has to discover its *own* PID and write that to a PID
> file. And your init structure has to rely on that somehow? That's what
> the start-stop-daemon hack was introduced to try to work around, by
> the way.
Which means we need a daemon (but not at pid 1) that is the absolute
parent of all system processes, impossible to sever, and another that
is the absolute parent of all non-system processes, impossible to
sever. (And probably absolute parents for login sessions and absolute
parents per user, which takes some significant redesign, but we can
push that redesign work off for a while, because none of this is
directly managed by pid 1.)
Eventually, we'll have a service id or a daemon id that is separate
from the pid, and managed by a non-pid-1 process. (cgroups tries to do
this and misses the mark.)
> Hacks on top of hacks to work around hacks. That's sysvinit. It is not
> salvageable.
Not salvageable without a lot of work.
But the lot-of-work factor comes into play whether we start from
scratch or are willing to refactor what is there.
> Does that mean systemd is the ideal replacement? No. Systemd has these
> overreaching tendrils in places it's got no business sticking tendrils.
> Why does it have its own ntp daemon? Why does it implement file system
> automount behavior? These things already exist as userspace processes.
> Mature, trusted userspace processes, sometimes with multiple competing
> alternatives already.
And this is why systemd should have been developed in a fork of
Fedora, and why, since it wasn't, should have been integrated into a
fork of debian instead of directly.
> But then on the other hand, what else would you use instead of systemd?
> Nobody has proposed a superior alternative yet, that I've seen.
Lot's of people have proposed superior alternatives, but RedHat was
not patient enough, management didn't want to understand engineering,
etc. And the systemd cabal has a certian charisma. (If you think
"charisma" means "nice", go look the word up again.)
> So, IMHO, the best thing to do is to use systemd, but don't use any of
> its optional intrusive tendrils. Other people have other opinions, and
> that's awesome. A healthy, vigorous competitive environment benefits
> all of us.
Fortunately, a lot of people are standing up to the cabal.
> My wheezy servers use wheezy's sysvinit + daemontools. My locally
> installed services are managed by daemontools. Debian's services are
> managed by sysvinit.
>
> On my jessie machines, I have systemd (with its syvinit compat layer)
> plus daemontools, started as a systemd service. I'm slowly transitioning
> my local stuff from daemontools to systemd services, but I am in no hurry
> to do so.
What we needed was probably for a group like Canonical to have funded
development of several alternative services management systems earlier
on. What we need now is for Redhat to back off just a little more than
they already have.
--
Joel Rees
I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html
Reply to: