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 27, 2014 14:22 UTC (Mon) by xxiao (guest, #9631)
In reply to: A call for votes in the Debian init system discussion by torquay
Parent article: A call for votes in the Debian init system discussion

I was never convinced that SystemD is superior technically, as an embedded guy I actually hate it.


(Log in to post comments)

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 14:53 UTC (Mon) by bangert (subscriber, #28342) [Link]

> as an embedded guy I actually hate it.

care to elaborate what reasons there could be for "an embedded guy" to "hate it"?

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 15:12 UTC (Mon) by ovitters (subscriber, #27950) [Link]

It would be nice if you expanded on the why. Especially considering how many embedded people make use of systemd nowadays.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 18:06 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm an embedded system guy and I love systemd. It allows to run sshd, ftpd and other tools on demand and to cleanly shut them down when they're not needed.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 4:54 UTC (Tue) by torquay (guest, #92428) [Link]

    I was never convinced that SystemD is superior technically, as an embedded guy I actually hate it.
In contrast to systemd, upstart has many fundamental problems, as explained here. These problems are acknowledged by the creator of upstart, Scott Remnant. While systemd is not perfect, it is a far better technical solution, learning from the mistakes made by upstart.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 11:49 UTC (Tue) by koenkooi (subscriber, #71861) [Link]

First, it's 'systemd', not 'SystemD' second as an embedded person I absolutely love systemd. It allows me to reject vendor sysv scripts and it makes my devices behave more like people expect, since systemd unified a lot of things across distros.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 14:11 UTC (Tue) by johannbg (subscriber, #65743) [Link]

I think it's time to show people a climbs into the bigger picture of systemd usage in the embedded space before people get the notions that since it does not work for you or you are not "convinced" it might not work for them or be unusable in some way on embedded.

So alot of people claim systemd is not for embedded or being used by embedded people when the fact is that from day one it was designed with embedded and in close collaboration with embedded developers like from profusion.mobi which since then has been acquired by Intel Corporation and integrated into it's Open Source Technology Center etc.

So let's look at couple of features it brings to the embeddeded world

* Aggressive parallelization systemd boot.

* Monitoring of every process it starts.

* Flexible application restart mechanisms.

* Centralized place to look for logs.

* Support for watchdog chaining.

* Very flexible dependency mechanism.

* Provides the tools to debug and diagnose the init process: systemd-analyze, systemd-cgls, systemd-cgtop, bootchart, pybootchargui, etc.

* On demand launch of services can improve boot time and conserve resources.

* Extremly flexible timer-based activation.

etc. etc. etc.

Let's take a brief look at few of those who are using systemd today in the embedded space.

Ångström you know the distribution tailored for embedded devices and is shipped with the BeagleBone Black, BeagleBoard-xM and BeagleBone it runs systemd.

Yocto Project which is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture yup it runs systemd.

Sailfish which is a Linux-based mobile operating system developed and run on smartphones by Jolla. Hey there systemd

*Any* GENIVI specification-compliant Linux®- based open source infotainment (IVI) product on the market runs systemd and let's see what GENIVI says about systemd...

"'Systemd' is an emerging technology for improving startup efficiency and control. In-vehicle infotainment users (drivers and passengers) expect the system to be functioning within seconds after turning the key, unlike well-known mobile devices such as smartphones that may take minutes to start up from full power-off. Unlike phones and PCs, cars cannot leave the infotainment system in a suspended state because the vehicle battery will run down potentially preventing the car from starting." By enforcing systemd, drivers can be assured that their GENIVI-based infotainment head unit, though packed with features more like an Android- or iOS-based smartphone, will be no more burden on the battery than an AM/FM radio with built-in digital clock. And it'll turn on just as quickly, too."

Tizen an open source, standards-based software platform supported by leading mobile operators, device manufacturers, and silicon suppliers for multiple device categories such as smartphones, tablets, netbooks, in-vehicle infotainment devices, and smart TVs.

I think it should be clear now by this brief look into the embedded space that systemd is being used in smartphones, tablets, netbooks, in-vehicle infotainment systems, smart TVs in addition to all the distributions running systemd and using it collaboratively and collectively between themselves which in turn cover open and enterprise server/desktop space.

A call for votes in the Debian init system discussion

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

My experience with systemd in embedded systems has not been that great. I find it overly complicated and a bit bloated. Well, it was the last time I looked which was about a year ago. Does no one care about system size or boot performance any more?

Most of time I prefer busybox init (without sysvinit scripts). I like to start everything myself, thank-you-very-much, exactly when I decide, during boot. I think that most developers doing aggressive management of their boot time are very much still in the 'manually-controlled-startup' camp, but I could be wrong.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 19:27 UTC (Tue) by HelloWorld (guest, #56129) [Link]

systemd's socket activation makes it boot faster than any other init system ever could. You just can't get this kind of parallelization without socket activation. So yes, you very much are wrong.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 20:36 UTC (Tue) by johannbg (subscriber, #65743) [Link]

I though busybox version of parallelization was adding "&" after every command and starting them all at once :)

A call for votes in the Debian init system discussion

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

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.

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.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 22:13 UTC (Tue) by jwarnica (guest, #27492) [Link]

If you are already doing everything by hand, then you are already doing everything by hand.

Today you ignore SysV, tomorrow you ignore systemd.


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