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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544e6fba.7090...@iwakd.de
