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:46 UTC (Tue) by tbird20d (subscriber, #1901)
In reply to: A call for votes in the Debian init system discussion by HelloWorld
Parent article: A call for votes in the Debian init system discussion

You seem pretty certain, but you may not be familiar with the types of systems I'm talking about.

I don't know the technical details, but I'm sure the socket activation you refer to will include extra communication with the systemd program (and hence extra task switches and syscalls), beyond a simple fork-and-exec. Add to this the page faults for the working set of systemd, as opposed to those for the init part of a stripped-down busybox. (At this level of optimization, page faults dominate the boot performance.)

I'm sure systemd is an improvement over other desktop-based init systems, and much more flexible than manually calculating the task dependencies (before boot) and forking-and-execing the programs individually. But I'll stick to my assertion that the latter is ultimately faster.


(Log in to post comments)

A call for votes in the Debian init system discussion

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

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.

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.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 20:55 UTC (Tue) by dashesy (guest, #74652) [Link]

You can dumb down the systemd to a serialized fork-and-exec, being a embedded system you probably need that level of customization from any init system anyways. I fail to see how a compiled binary could be slower than shell scripts!
At the minimum all those grep processes to get the input (!) will be unnecessary.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 20:59 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> I don't know the technical details, but I'm sure the socket activation you refer to will include extra communication with the systemd program (and hence extra task switches and syscalls)
So you just want to fork a copy of dash/busybox for each SysV-init script? Do you know that systemd allows to boot a system without using shell AT ALL?

Of course, you might want to do one big-ass shell file which starts all the services. But this kinda stinks - it's buggy and error-prone and doesn't scale.

A call for votes in the Debian init system discussion

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

Wow. I'll answer the other responses along with yours. I never said anything about launching shell scripts, or even busybox sh for anything. I specifically said I use busybox init (a compiled binary), without the sysvinit stuff in inittab. This also allows you to boot a system without using a shell, although in my case it is fairly common to use one big shell file to start the few services I need, then get replace it during boot optimization.

I agree with your assertion that it is error-prone and doesn't scale. But it boots very fast. Sometimes user time is more important than developer time, but this is very product-specific.

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 0:40 UTC (Wed) by josh (subscriber, #17465) [Link]

> I don't know the technical details, but I'm sure the socket activation you refer to will include extra communication with the systemd program (and hence extra task switches and syscalls), beyond a simple fork-and-exec.

No, it doesn't. systemd already has to fork-and-exec the service; systemd just sets up the socket first, and lets the process inherit that socket. In particular, socket activation means you can launch services A, B, and C in parallel, even though B and C depend on A, because systemd has already created A's socket before launching A, B, and C.

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 15:55 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> In particular, socket activation means you can launch services A, B, and C in parallel, even though B and C depend on A, because systemd has already created A's socket before launching A, B, and C.

Even better, you can launch A, B, and C in parallel even if A depends on B, which depends on C, which depends on A. Circular dependencies between services are not a problem. You just have to avoid creating deadlocks where there are circular dependencies in the *responses*. Try doing that without socket activation! There is no way to start such services sequentially; all the sockets have to exist before any of the services can start.


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