Re: Perfect Jessie is something like this...
Am 27.10.2014 15:05, schrieb Dimitrios Chr. Ioannidis:
> Στις 27-10-2014 14:53, Christian Seiler έγραψε:
>> To me a lot of the anti-systemd response here seems to be a purely
>> gut-driven emotional response. I realize that what kind of preferences
>> we have in the software we want to use has a large emotional component.
>> For example, I don't think you can put my opinion of GNOME into purely
>> technical terms.[3] So I don't think that it's a bad thing for people
>> to
>> say "I am emotionally attached to sysvinit and want to keep using it",
>> but to rant against a dependency on something that DOES NOT PREVENT YOU
>> from doing so, doesn't seem to be a very rational way of going about
>> things to me.
>
> A quick search reveals the following.
>
> I've a software that use libuuid. Until now, the uuidd had the ability
> to start on-demand the uuidd if the later, quotting "... setuid to an
> unprivileged user (e.g. uuidd:uuidd)".
>
> After that commit[1], i'm forced to use systemd, if i don't want to
> start uuidd from the beginning. That's new for me...
>
> [1] http://www.spinics.net/lists/util-linux-ng/msg09698.html
Could you do me a favor and reread the paragraph I wrote? I explicitly
said that I didn't have a problem with people saying that they wanted to
continue using sysvinit for whatever reasons, I was merely responding to
the fact that some people have an allergic reaction to anything that
contains the word 'systemd' (going so far that some people extend that
disdain to the compatibility layer called 'systemd-shim' that is NOT
written by the systemd authors), and I was directly responding to an
email where somebody was complaining about libsystemd0.
In your case, the technical part of your issue lies not in the fact that
uuidd supports systemd-style socket activation. Your issue is with the
fact that after socket activation was added to uuidd, the previous
on-demand starting method was removed from it. So the core issue is that
they removed a feature you were using, not that they added another.
Btw. the commit you are referencing just updated the init script, the
change in libuuid was done over 2 years ago:
<https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/libuuid/src/gen_uuid.c?id=ea4f8845f0241c714f9487ece5bb6900fc18a9e0>
That all said: I can understand why the util-linux people wanted to get
rid of the old on-demand mechanism: it's potentially error-prone and may
leak context from the program using libuuid into uuidd.
Say, for example, you put the daemon using libuuid into a cgroup - not
with systemd, but with for example cgconfig. And then that daemon starts
uuidd because it's the first to request a UUID. uuidd will then live in
the same cgroup as the daemon. If the administrator then uses the
'freezer' cgroup to atomically stop the entire service that initially
started uuidd, then uuidd will get stopped alongside with it as
'collateral damage'. And then other services using it will block because
uuidd is still running but they have to wait until it responds again.
This just being one example of context being leaked. Some of this
context could be cleaned up if uuidd were setuid root (and not setuid
uuidd), but not all of it necessarily.
Now, this probably will not have been a problem in your specific case.
So yes, you lost a feature there. But put yourself in the perspective of
the developers of util-linux:
- drop an error-prone and potentially security-relevant mechanism for
on-demand startup
- add support for on-demand startup that will work on a large number
of installations (systemd being quite prevalent already then)
- on all other installations: it will now have to be started from the
very beginning
Obviously, the latter part is not optimal for you, but uuidd will keep
working on your system, so I don't see what the huge problem is. If
something on my system goes from socket activation to always started or
the other way around, I usually don't care that much, as long as it
keeps working.
To be honest, let's say there was no systemd, no socket activation,
nothing. If people had asked me (which they wouldn't have, but anyway
;-)), I would have advised the util-linux developers to remove on-demand
activation via fork/exec anyway, because of potential problems, and
always start it at boot. (It's not like it's a database server that
takes forever to start and takes up tons of RAM.)
Finally: Upstart also supports socket activation. It's not quite as
powerful as systemd's, but is has enough features for this use case. I
don't know the people developing util-linux, but I could imagine them
accepting a patch to also support Upstart-style socket activation, if
one were to write such a patch.[1]
Also, if you have an idea of how to solve on-demand activation without
socket activation in the init system but not using the same hack as
libuuid did before, then I can also imagine them accepting such a patch.
Christian
[1] Or, if you want to: a while back I wrote some code to translate init
system related stuff between one another. Since there was next to no
interest in it, I didn't continue working on it, but my guess is that
you could probably get on-demand uuidd working working together with an
Upstart job and Upstart's socket activation using that code.
https://github.com/chris-se/cross-init-tools
Reply to: