The "Devuan" Debian fork

Posted Nov 30, 2014 17:12 UTC (Sun) by patrakov (subscriber, #97174)
In reply to: The "Devuan" Debian fork by mgb
Parent article: The "Devuan" Debian fork

Well, technically, systemd (even before it was transformed into a hungry hippo) contains one new semi-technical idea which does put it well above any other dependency-based boot manager. The idea is to tell people to start eliminating dependencies instead of (often incorrectly) expressing them. Here I am talking about such things as automounting filesystems (which can be potentially used to eliminate dependencies on "/var being mounted"), IP_FREEBIND, socket activation (to eliminate the dependency on the network being up) and so on. Very good ideas, but, unfortunately, some of them are not portable to non-C languages.

The "Devuan" Debian fork

Posted Nov 30, 2014 18:39 UTC (Sun) by gracinet (guest, #89400) [Link] (4 responses)

Out of curiosity, are you thinking of a specific non-C language ?

The "Devuan" Debian fork

Posted Nov 30, 2014 19:12 UTC (Sun) by patrakov (subscriber, #97174) [Link]

Actually about several.

Node.js is so far the biggest offender, because it is plain impossible to write a correct UDP-based server in it that works on a multihomed system without resorting to timer-based polling of os.networkInterfaces(). Here "correct" means the following:

1. It must reply from the same of the several IPs belonging to a host where the UDP request came in.
2. It must deal with interfaces going up and down, appearing and disappearing, and the same for their IP addresses. In particular, it must not demand that all "interesting" IP addresses exist on the interfaces at startup time. Bonus points for not requiring to list all potentially-interesting IP addresses explicitly.

I have expressed the issue in one of the comments to https://github.com/joyent/node/issues/8788 (no IP_FREEBIND, no IP_PKTINFO, no revcmsg/sendmsg (required to actually use IP_PKTINFO), no way to get notified about network configuration changes).

The second, smaller, offender is Python 2.7. It is possible to hack IP_FREEBIND into it (and bind to all "interesting" addresses in advance, even before they appear on interfaces), but not IP_PKTINFO (because of no recvmsg/sendmsg). Also good is that unofficial netlink bindings exist, so one can watch interfaces and IP addresses coming and going without resorting to timer-based polling.

Python 3.3 does have recvmsg/sendmsg support, and IP_PKTINFO can thus be hacked in. Ruby even has ip_pktinfo support out of the box.

The "Devuan" Debian fork

Posted Nov 30, 2014 20:20 UTC (Sun) by cortana (subscriber, #24596) [Link] (2 responses)

There's no IP_FREEBIND, or (easy) way to do socket activation/monitoring of available network interfaces available in Java.

The "Devuan" Debian fork

Posted Dec 1, 2014 1:07 UTC (Mon) by lsl (subscriber, #86508) [Link] (1 responses)

What's the problem with socket activation, i.e. letting systemd pass your program the listening socket(s)?

That should be trivial to do in any programming language, as the file descriptors are just inherited from the parent process. It's there without you doing anything. The count of inherited FDs is passed in the environment (as LISTEN_FDS) and they start at 3.

Sure, there's the sd_listen_fds(3) C API but you don't actually have to use that. Especially not if calling into C involves unholy things like JNI.

Am I missing something?

The "Devuan" Debian fork

Posted Dec 1, 2014 4:42 UTC (Mon) by patrakov (subscriber, #97174) [Link]

You are missing the fact that it is impossible (no API) to properly import already-opened file descriptors into node.js event loop as UDP sockets.

For TCP client sockets, this functionality does exist (new net.Socket([options])), but you can't import an already-existing listening TCP socket by fd. So even for TCP, supportable socket-activation functionality is limited to inetd-style daemons that are executed anew for each incoming connection.

The "Devuan" Debian fork

Posted Nov 30, 2014 19:31 UTC (Sun) by mgb (guest, #3226) [Link] (1 responses)

> The [systemd] idea is to tell people to start eliminating dependencies ...

A well-designed dependency-based boot manager might have some value on a laptop but production servers cannot rely on trying to guess all the O(N*2) dependencies between components.

Incidentally, all of our systems - servers, VPSs, laptops, and desktops - have one or more inittab entries to bring up serial consoles, maintenance networks, maintenance sshd, etc. Sysvinit tries them and if something fails it waits and tries again.

They work perfectly precisely because they don't rely on systemd-ish human-error-filled notions of trying to specify exactly which network interfaces and file systems need to be up and mounted.

The "Devuan" Debian fork

Posted Nov 30, 2014 19:41 UTC (Sun) by patrakov (subscriber, #97174) [Link]

In general I agree with your comment, except for the fact that you call the idea of specifying the exact dependencies "systemd-ish". It isn't. It (in the form of LSB headers) predates both systemd and upstart.

And in many contexts (in particular, in clusters where the service depends on something remote) trying and retrying until success is indeed the only working solution. The only possible disagreement here is whether such retrying should be done by the service or by the service manager, but I don't have a strong opinion here.