On Tue, Feb 25, 2014 at 1:42 AM, Yuri K. Shatroff <yks-...@yandex.ru> wrote:
> On 24.02.2014 18:33, Mark David Dumlao wrote:
> Sorry but I think I was quite clear:
>
>>>>> An init daemon generally does one thing well.
> Following a "Unix way" design, Everything else should be done by something
> else.
...
>> At least with systemd the parts are cleanly split off into separate
>> executables.
>> Yes, it's technically not needed for pid 1 to create tempfiles for
>> other programs.
>> That's why systemd-tmpfiles is its own tiny program, that does one "one
>> thing"
>> (create tempfiles for other programs) and nothing else. Yes, it's
>> technically
>> not needed for pid 1 to check your filesystems. That's why systemd-fsck is
>> once again, a separate utility, that does "one thing" (run fsck) well.
>> Yes,
>> it's technically not needed for pid 1 to remount your filesystems
>> readwrite.
>> Again there's a separate utilty for that, that does nothing but just that.
>
>
> Okay, but can I take them out and substitute mine own easily? How? Is there
> a well-defined standard? Is there a well-defined objective, a target at
> which the systemd software set will be considered stable 'version 1.0'? I am
> asking again, if a bug is found in the systemd infrastructure, is it
> possible (i.e. how much effort it would take) to fix it temporarily on a
> running system?
>
It's almost as if you don't bother reading the docs on something, then
comment that they're impossible.
Yes you can take them out and substitute yours, in fact I just
mentioned that I could replace them with plain old init scripts.
systemd services are controlled by the same unit files that control
other services.
>> OpenRC is often spoken of in the same breath as systemd, as if they were
>> the same kind of thing. That sounds fair but think about it for a second:
>
>
> Sorry but did I mention OpenRC?
>
There is a context to this conversation that you appear to be selectively
ignoring, wherein openrc, sysvinit, and systemd are being compared, and
only one of them is being demonized as anti-Unix. I compared systemd above
_both_ to openrc and to sysvinit. The point being ethat systemd is not
comparable to _just_ init, but to the whole init ball of wax.
>
>> openrc - as most people talk about it - isn't even pid 1. as most people
>> talk about it, openrc includes the functions.sh, the net.eth0 scripts,
>> the script
>> for starting your /sys, /proc, mounting local and network filesystems,
>> setting
>> the hostname and so on.
>
>
> Obviously. That is why OpenRC *can* be treated as a "Unix way" thing,
> because the whole bunch are pretty interchangeable, independent and do their
> own things well, don't they?
>
interchangeable:
I also pointed out that the systemd parts, like openrc parts, are
interchangeable, and do their own things well. I did mention, for example,
that I could replace systemd-fsck with an init script. Heck I could disable
it entirely if I didn't care about fsck (for instance, in a container). Likewise
the mount unit the network units, etc etc can be disabled or replaced
if wanted.
independent:
I do not think independent is an important concept for Unixness, as most of
the parts of postfix, dovecot, xorg, qmail, squid, etc are not independent.
What you DIDN'T and have not been able to point out is what this one thing
that pid 1 is supposed to do.
What you also have not been able to demonstrate is that openrc or other
init systems' parts follow the same criteria. There's was a long-standing bug,
for instance, in that functions.sh has not been separated from openrc.
I believe Canek was one of the people pushing to have it done so - to
better support systemd - something that violates "independence" and
"interchangeability".
> Sorry, do you mean *everything* in /etc/ is to be configured? That's a
> convention to put the init stuff in /etc/. You could as well put it in /usr,
> /boot, wherever. In FreeBSD, the local init stuff resides in /usr/local/etc.
> In Solaris, elsewhere. In AIX, elsewhere. Why do you look at everything from
> a single linux's angle? Please note, I never say the 'linux way' but the
> "Unix way".
/etc scripts ARE meant to be configured. At the very minimum, from the
perspective of gentoo, they are treated by the conf-update tool as config files.
You are expected to copy and customize init scripts for custom or local
daemons.
> And you might also notice, an init system does not really much depend on the
> init daemon. It's pretty possible to run a SysV init daemon on a BSD system,
> or the opposite, because all the init daemon does is start some init
> scripts. Maybe /etc/rc, maybe /etc/init.d/* ...
This is besides the point. Different programs are free to rely on different
standards and different features. That openrc can't work or depend on
systemd is not systemd's fault, in the same way that not all parts of
postfix can work or depend on all parts of qmail.
None of this says anything about the unixiness of postfix or qmail, none
of this says anything about the unixiness of init or systemd.
> No, really. What does systemd *add* what is missing and impossible to do
> with OpenRC?
>
That's really besides the point to me. This issue is supposed to be whether
systemd is unix-like or not. 1, you haven't shown how the traditional init
follows even your own notions of unixness. 2, you haven't show how systemd
fails to follow the same notions of unixness as the traditional init.
If you're really looking for one, I pointed out two earlier in this
thread. systemd
reliably stops services (openrc and sysvinit simply silently fail) and
allows you
to debug the exact command line in seconds (glance at the unit file) as opposed
to minutes (parse the init script).
> The init scripts altogether don't do one thing, and I never said this. A
> single init script usually does.
No seriously, a lot of init scripts - even individually - do not do one thing,
nor do they do it well.
> Why not always quite well? Because it
> depends not only on the script, but on the software itself. Do you claim a
> systemd unit file does the thing better than a shell script? No it just
> can't, I see many (if not most) of the unit files just issue commands.
> The problem of the current SysV init system is that during its history there
> was a great number of different people writing different scripts in
> different styles as per their understanding of 'well'. But these could
> easily be conducted to a standard, actually e.g. FreeBSD has no problem with
> init scripts. Neither do I think OpenRC does.
init scripts fail because
1) they don't do just one thing.
for example, they try to create temp files and directories, and don't properly
exit / fail when those conditions are broken. there is a common sysad
problem where if you accidentally start a service as root you bork any
chances of the script starting it. that's acceptable, ok.
but worse than that, many init scripts _silently_ fail, because creating
files and directories with the right permissions is not really its "one thing".
2) they don't properly track process ids, because they rely on pid files rather
than tracking all spawned / forked processes.
It seems to me that - barring kernel hints - tracking all spawned and forked
processes is the job of the process that spawned them and something
that it would be in a position to inform the scripts of. in systemd I think
pid1 does the spawning, so naturally pid1 does the tracking. It just so
happens that it does so using cgroups.
So yes, as of right now, in the real world, unit files are better than
init scripts,
EVEN IF they issue the same commands, simply for breaking and terminating
more reliably.
> In fact, by chance I'm here a 'sacrifice' because many things you (and other
> posters) attributed to me I either didn't say at all or said quite
> differently. ('Bloated systemd' is one example; comparing the whole systemd
> infrastructure to a single init daemon is another, etc.)
>
I didn't attribute anything to you you didn't say. It just so happens, though
that there is a context to this conversation, which, if you ignore, just
tends to perpetuate a lot of confusion. I am responding to questions and
points in that context for the benefit of the larger conversation, not
just for you.
--
This email is: [ ] actionable [ ] fyi [x] social
Response needed: [ ] yes [ ] up to you [x] no
Time-sensitive: [ ] immediate [ ] soon [x] none
