Debian TC vote on init system coupling

Posted Feb 26, 2014 22:53 UTC (Wed) by viro (subscriber, #7872)
In reply to: Debian TC vote on init system coupling by anselm
Parent article: Debian TC vote on init system coupling

Excuse me, but... WTF bother with dumping on disk? My one and only involvement with sysvinit was something very similar, and it works just fine, but you don't need any writable filesystems in sight, let alone ones with sufficient free space, etc.

Just call pipe(2), fork, have parent call execve(), notice that it had been asked to re-exec itself and that pipe is there, then have child serialize the state and feed it into pipe, with parent fetching it from there.

Not much harder than disk variant and a _lot_ more robust; there's a whole lot of failure modes that disappear that way. Sure, you need to block all signals before forking, but you need it for other reasons anyway...

Debian TC vote on init system coupling

Posted Feb 27, 2014 3:40 UTC (Thu) by tao (subscriber, #17563) [Link] (2 responses)

Sounds like a sensible idea. I'm sure the systemd developers would love a patch :)

Debian TC vote on init system coupling

Posted Feb 27, 2014 4:25 UTC (Thu) by raven667 (subscriber, #5198) [Link]

That's presuming that the original description isn't a misunderstanding of how systemd PID 1 works

Debian TC vote on init system coupling

Posted Feb 27, 2014 4:51 UTC (Thu) by viro (subscriber, #7872) [Link]

*shrug* If they need it, they can write it. For sysvinit it took me about a weekend (IIRC - that was 16 years ago) to write and debug and most of that consisted of writing the marshalling code. That they already have, apparently, so it ought to be a few hours worth of work, from start to finish, including building and testing. Not my problem, seeing that I'm not using systemd for a lot of reasons. And no, for me the lack or presence of such reexec functionality isn't anywhere near those.

Don't read into that comment anything other than a surprise at the decision to use an on-disk file for passing the state. All software is full of WTFs of that kind and the life is too short to fix ones in the stuff one doesn't use. I have more than enough fun with the kernel and with the userland I do use, TYVM. If I run across something of that kind in e.g. OpenBSD kernel, or djbdns, I'll probably comment on it and move on. Same as with systemd. Has nothing to do with my (lack of) liking of their authors, before anyone goes into that - if I run across something fishy in glibc or openssh, I *will* do more than commenting, no matter how little I am fond of Ulrich and Theo resp.

Same reason why I won't contribute to GNOME or emacs - I don't use either, they are not within 0.01% of programs that are pleasant to read, I'm not interested in developing them and it's not even what I'm paid for. Bugs in e.g. nvi are something I will deal with (and had done so in the past), something similar in aforementioned emacs... apt-get remove emacs\* solves them all nicely, as far as I'm concerned.