A call for votes in the Debian init system discussion
Posted Jan 27, 2014 14:53 UTC (Mon) by bangert (subscriber, #28342)
care to elaborate what reasons there could be for "an embedded guy" to "hate it"?
Posted Jan 27, 2014 15:12 UTC (Mon) by ovitters (subscriber, #27950)
Posted Jan 27, 2014 18:06 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Posted Jan 28, 2014 4:54 UTC (Tue) by torquay (guest, #92428)
Posted Jan 28, 2014 11:49 UTC (Tue) by koenkooi (subscriber, #71861)
Posted Jan 28, 2014 14:11 UTC (Tue) by johannbg (subscriber, #65743)
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.
Posted Jan 28, 2014 18:23 UTC (Tue) by tbird20d (subscriber, #1901)
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.
Posted Jan 28, 2014 19:27 UTC (Tue) by HelloWorld (guest, #56129)
Posted Jan 28, 2014 20:36 UTC (Tue) by johannbg (subscriber, #65743)
Posted Jan 28, 2014 20:46 UTC (Tue) by tbird20d (subscriber, #1901)
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.
Posted Jan 28, 2014 20:53 UTC (Tue) by mathstuf (subscriber, #69389)
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.
Posted Jan 28, 2014 21:22 UTC (Tue) by tbird20d (subscriber, #1901)
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.
Posted Jan 28, 2014 21:56 UTC (Tue) by mathstuf (subscriber, #69389)
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
Posted Jan 28, 2014 21:58 UTC (Tue) by mathstuf (subscriber, #69389)
Posted Jan 29, 2014 16:28 UTC (Wed) by paulj (subscriber, #341)
So I wonder just how much this will get used in the long-run.
Posted Jan 29, 2014 17:26 UTC (Wed) by raven667 (subscriber, #5198)
Posted Jan 29, 2014 17:43 UTC (Wed) by paulj (subscriber, #341)
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?
Posted Jan 29, 2014 17:52 UTC (Wed) by raven667 (subscriber, #5198)
Posted Jan 28, 2014 20:55 UTC (Tue) by dashesy (guest, #74652)
Posted Jan 28, 2014 20:59 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Jan 28, 2014 21:13 UTC (Tue) by tbird20d (subscriber, #1901)
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.
Posted Jan 29, 2014 0:40 UTC (Wed) by josh (subscriber, #17465)
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.
Posted Jan 29, 2014 15:55 UTC (Wed) by nybble41 (subscriber, #55106)
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.
Posted Jan 28, 2014 22:13 UTC (Tue) by jwarnica (guest, #27492)
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