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 0:38 UTC (Mon) by drag (subscriber, #31333)
In reply to: A call for votes in the Debian init system discussion by hummassa
Parent article: A call for votes in the Debian init system discussion

Kfreebsd should probably end up using whatever FreeBSD comes up with to replace their current init system.

Like this guy: https://github.com/rtyler/openlaunchd

Most of the major software projects are going to probably want to remain compatible with FreeBSD so they will have their own init scripts/configs for that init systems already.


(Log in to post comments)

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 1:23 UTC (Mon) by dashesy (guest, #74652) [Link]

It was a recent article I think that kFreeBSD had wisely decided to remove BIND, who knows maybe they also will decide to get rid of sendmail, sysv-init and other 90s cruft, good for them. Clearly systemd is superior to all other alternatives for *Linux*, this seems like a logical and clear decision, engineers who value anything but technical merits will eventually harm their beloved project, look at the recent discussion about gcc's historical reluctance to modular design. Not a Debian user, but I hope Steam might finally achieve a Linux desktop for all, yes desktop form-factor will be a niche market but I hope it still gets subsidized for gamers sake and not just developers, that is why I do care if debians make a good technical decision.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 4:33 UTC (Mon) by wahern (subscriber, #37304) [Link]

Portability is a technical merit, IMNSHO. Lennart is in the minority when it comes to his dismissal of the value of POSIX, and portability in general.

Your epithet about "90s cruft" is hardly a technical argument, and is telling.

The startup system isn't as big a deal as people make it out to be. If it were, then inetd(3) and DJBs daemon tools would have gained much more traction over the years.

It's more of a deal on single-user interactive devices than on multi-user server systems, because there you have a ton of centralized processes interacting in complex ways. Yet it's the single-user device systems where systemd is the least likely to become the predominant system.

For all the people confused as to why even those who agree that systemd is technically superior are reticent to adopt it, it's because the absolute value is very small, and it's million+1 features are unlikely to be widely adopted even by most Linux software. On the other hand, the cost of switching and being locked into systemd for the foreseeable future is considerable.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 7:00 UTC (Mon) by rodgerd (guest, #58896) [Link]

> Portability is a technical merit, IMNSHO. Lennart is in the minority when it comes to his dismissal of the value of POSIX, and portability in general.

Portability of PID 1. Hmm. Let's see. That would be the PID 1 that's unique on Mac OS X, Solaris, uses BSD semantics on the FreeBSDs. That portability? And the shell scripts it relies on which expect different shells on those platforms.

I guess your definition of portability is formed under some parallel universe where PID 1 and init scripts are portable. They haven't been in this one since BSD split off.

> It's more of a deal on single-user interactive devices than on multi-user server systems, because there you have a ton of centralized processes interacting in complex ways.

The fact you think this honestly makes me wonder how much server admin you've done.

A call for votes in the Debian init system discussion

Posted Feb 1, 2014 21:46 UTC (Sat) by JanC_ (guest, #34940) [Link]

You are comparing the default init / PID 1 on those systems instead of the possibility to run the same (or a functionally equal) implementation of it on all those platforms. "Portability" refers to the latter here, I think...

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 7:22 UTC (Mon) by torquay (guest, #92428) [Link]

    Portability is a technical merit,

Portability to what? The amount of folks using various BSD flavors is miniscule compared to Linux. What exactly does *BSD bring to the table that Linux doesn't? It might be more telling to ask a related question: what functionality is missing in *BSD that Linux provides?

If we look only at Debian, the overwhelmingly largest number of installations use the Linux kernel, not the FreeBSD kernel. Why should a very tiny minority hold back the vast majority? The *BSD folks are welcome to implement their own sysvinit replacement, or to implement functionality that the Linux kernel provides.

However, as has been mentioned before, to a large extent sysvinit scripts can be generated from systemd unit files. While this is a workaround solution, it indicates that just because Debian+Linux might use systemd, the use of systemd does not automatically rule out the FreeBSD kernel within the Debian world.

    IMNSHO. Lennart is in the minority when it comes to his dismissal of the value of POSIX, and portability in general.

I don't believe there is a dismissal of POSIX here. Instead, it's thorough work based on realistic acknowledgement that POSIX has its limits. POSIX is undoubtedly useful, but to make a more robust system which also has less maintenance requires functionality beyond POSIX.

    the cost of switching and being locked into systemd for the foreseeable future is considerable.

As opposed to cost of switching and being locked into upstart, or the cost of switching and being locked into launchd ? There is always going to be cost no matter the choice. However, by being stuck with sysvinit we also have the maintenance burden cost as well as technical debt. When switching to a new system, why not make the best technical choice ?

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 14:22 UTC (Mon) by xxiao (guest, #9631) [Link]

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

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.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 8:29 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> Portability is a technical merit, IMNSHO. Lennart is in the minority when it comes to his dismissal of the value of POSIX, and portability in general.

Others already said that portability of PID 1 is a red herring anyway. I'll also add that portability leads to just another lowest common denominator solution. That's what Lennart's "opposition" to portability boils down to: he wants to unleash the power of all the features in Linux and creating an inferior solution in the name of portability is clearly not the way to go.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 10:51 UTC (Mon) by vonbrand (guest, #4458) [Link]

Funny that systemd is about managing services; that it also handles system boot is almost incidental...

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 12:52 UTC (Mon) by zenaan (subscriber, #3778) [Link]

> Portability is a technical merit, IMNSHO. Lennart is in the minority when it comes to his dismissal of the value of POSIX, and portability in general.

An old debate between Tanenbaum and Linus Torvalds comes to mind :)

At the end of the day, Linux got ported, because people did the work. Now it runs on most anything. If the Debian KFreeBSD guys want systemd ported, they can do the work. They might prefer something else though.

> For all the people confused as to why even those who agree that systemd is technically superior are reticent to adopt it

Actually, systemd has wide adoption, just like git. Debian would be the hold-out if it doesn't adopt systemd, but either way, due to its technical features and those who appreciate what it provides, it shall continue to be packaged in Debian, just like every other init out there that has enough supporters who appreciate that particular init.

> million+1 features .. the cost of switching and being locked into systemd

Hand waving; as others have said eloquently, put up or shut up.

A call for votes in the Debian init system discussion

Posted Jan 31, 2014 15:13 UTC (Fri) by sionescu (subscriber, #59410) [Link]

How is portability a technical merit in and of itselfe ? As I see it, it's mostly a political merit end even there, only if the other platforms to which the software is portable have enough users that can contribute back.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 8:23 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

No. You read that FreeBSD 10 was released and among other changes they decided to replace BIND in the base system with unbound.

kFreeBSD stands for "kernel" of FreeBSD. More specifically: a short for GNU/kFreeBSD (that is: "Linux" userspace, including glibc, on top of a FreeBSD kernel) or more specifically in this discussion to the Debian GNU/kFreeBSD port (Debian on top of a FreeBSD kernel).

BTW: Debian (and likewise Debian kFreeBSD) uses Exim as its default mailer.


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