User: Password:
|
|
Subscribe / Log in / New account

A call for votes in the Debian init system discussion

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 20:53 UTC (Tue) by mathstuf (subscriber, #69389)
In reply to: A call for votes in the Debian init system discussion by tbird20d
Parent article: A call for votes in the Debian init system discussion

With socket activation, you get to skip any actual fork/exec until something pokes the socket for communication. I'd expect systemd calling listen/accept on a socket is way faster than fork/exec'ing ssh or whatever other daemon systemd is listening for to do so (and by the time that happens, booting is done and the service should be fine starting up).

In addition, the systemd PID 1 executable is 1.2M here which is much smaller than my initramfs (11M) and vmlinuz image (5.1M). Sure, it links libraries, but all but libsystemd-daemon (15K) is likely to be linked by the rest of the daemons anyway.


(Log in to post comments)

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 21:22 UTC (Tue) by tbird20d (subscriber, #1901) [Link]

Socket activation does have some nice benefits for certain network-related services. So yes, systemd is handy for deferring certain types of startups until later. On some systems this will be useful. Just not mine.

My busybox images usually run under 500K, statically linked. But the working set for the init portion is smaller than that. I haven't compared this to the working set for systemd, but if the difference in working set size is comparable to the difference in binary size (including required libraries), then I still think busybox init is going to load up faster than systemd.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 21:56 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Out of curiosity, what kinds of systems are you using/creating? Here's my systemd status on Fedora 20 (it's a comparatively light system, but still not as stripped as possible):
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    1 root      20   0  132128   5860   3468 S   0.0  0.1   0:02.88 systemd
Looking at /proc/1/maps, SELinux is an easy target if you want to kick something out (3 pages with 11 anon pages between them; probably related). The heap is only using 9 pages.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 21:58 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

(I admit that I may be reading 'maps' completely wrong; feel free to educate me.)

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 16:28 UTC (Wed) by paulj (subscriber, #341) [Link]

Strange that inetd services weren't more popular, in that case. Seems there was a phase where it was fashionable, and a number of (now obsolete) services were written for inetd launching.

So I wonder just how much this will get used in the long-run.

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 17:26 UTC (Wed) by raven667 (subscriber, #5198) [Link]

inetd services are very simple, usually just forking a new process for each incoming connection, which doesn't scale on the big internet of today. I think it might have been more of a bridge to get applications on the network easily without writing network code, now most network apps have their own socket handling code. In the systemd case, it can startup services on demand which are long running and have their own socket handling code, which is kind of the best of both approaches. It probably won't be used for everything or even most things, but the few apps which benefit will have the feature available, for example SSH can defer until startup until the first incoming connection, and maybe even shutdown after a period of idleness, saving resources without affecting availability.

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 17:43 UTC (Wed) by paulj (subscriber, #341) [Link]

Inetd processes could persist. There generally wasn't a convention for also handing over listen sockets, so this was only useful on connectionless sockets / UDP. However, had there been a demand, handing over the listen socket could have been implemented easily, just as systemd does.

So, given the benefits, it's just weird that there wasn't more take-up of this. I agree socket activation is a good thing, and it'll be nice if systemd makes it fashionable again. I'm just curious why it didn't stay fashionable the last time around?

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 17:52 UTC (Wed) by raven667 (subscriber, #5198) [Link]

My opinion is that as UNIX became more popular with hardware vendors there was a greater push for standardization and portability, and enterprise support, which caused many services to get frozen in time with no new features added and no compatibility breaks allowed. Stagnation which has persisted until recently.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds