On Fri, 31.05.13 23:31, Helmut Grohne (hel...@subdivi.de) wrote: > debian-devel@l.d.o has been talking about socket activation interfaces. > The technical differences are nicely summarized: > > On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote: > > But chronology is less important then the technical differences between > > the two interfaces. > > > > In systemd a socket activated process gets the variable $LISTEN_FDS > > and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1]. > > The interface is very generic. > > > > In upstart the process gets one socket, with the number given in > > the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since > > there's only one socket, (b) is tied to upstart, and (c) there's only > > one socket. > > > > The limitation to one socket is quite constraining, e.g. we like > > apache to listen on both 80 and 443, and the requirement for apache to > > open the second port itselfs makes it impossible to start apache > > unpriviledged. > > > > Zbyszek > > > > [1] > > http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description > > [2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html > > Is there any chance for upstart to adopt the socket activation interface > from systemd? As has been pointed out above, the interface is more > generic. Having upstart and systemd differentiate on interfaces does not > serve any good. Instead upstart could benefit from daemons already > supporting systemd style socket activation. Having one interface to > socket activation would greatly reduce the amount of integration work to > be done by distributions such as Debian. I am aware that this is kind of > a bike shedding discussion. The value to be gained is the uniformity > though. > > If this is not possible, please briefly lay out the reason (or point to > previous discussion of this matter).
To provide a bit of context: we deliberately designed our socket passing logic to be generic enough to be implementable elsewhere than systemd (i.e. we kept it as minimalistic as possible and kept any reference to the systemd name out of it). I remember even emailing the Upstart guys about that, but I never got any reply. This was a long long time before Upstart added socket activation. Note that what Upstart eventually implemented regarding socket activation kinda misses the major point of it. Socket activation in the launchd/systemd sense is a tool that (among other things) allows you to get rid of ordering dependencies between clients and servers, and systematically parallelize their startup. Here's an example: if you have a syslog daemon and a service that logs to syslog, then the former is the server, the latter is the client. Now, let's say you want to start both at boot. In classic init systems you would have to make sure that you first start the syslog daemon, and only after that finished initialization -- and hence established the syslog socket in the file system -- you can go on and start the client. Hence you need to express this dependency, and if you don't do that you will lose messages. Now, if you employ socket activation for this, then you'd first establish the syslog socket from your init system, and then start the syslog daemon and its client *at the same time*. Since the socket is known to be established before your two services initialize logging will always just work -- and you do not have to express any dependency explicitly anymore! On top of that, parallelization is maximized since client and server start at the same time, and do not have to wait for each other (at least until the socket buffer runs full and the client starts to block, but that hopefully happens relatively late). Things hence get simpler, and faster at the same time! Now, if you understood the scheme above then you will have noticed that socket activation is *not* about lazy activation here. You start both services early on, and at the same time. You do not wait for an incoming connection. And that's something Upstart cannot do with its scheme. In Upstart, since the sockets are part of the socket connection event, you always need the connection to take place first. Hence: on systemd (and launchd where idea comes from) socket activation is primarily about getting rid of dependencies and increased parallelization. And secondarily about lazy activation. On Upstart however socket activation is about lazy activtion and nothing else. In my eyes this makes socket activation in Upstart pretty much uninteresting and misses the major point of it. (Well, at least to the level I understood Upstart. Maybe I totally missed how it works, but from the docs, it appears it cannot create the listening socket, and then activate its service from any other event than the actual incoming connection event of it, but still have the listening socket passed to the service.) Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130601015315.ga25...@tango.0pointer.de