Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview: Lennart Poettering

linuxvoice.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Interview: Lennart Poettering

#81

Post by gillianseed »

digi_owl wrote: post #57
jvreeland wrote: post #33

Earlier quoted context omitted.

Arch was one of the first to switch and while a decent number use gnome I sincerely doubt they made the choice because of gnome. Arch has a long history of alternative WM/DE It's not likely any individual one could force their hand on an architecture change like systemd.

The Arch switch was a decree from on high as best i can tell, with a very "deal with it" style forum posting. And i think at least one Arch offshot is not adopting systemd at this time.

Actually, the Arch devs said that if anyone stepped up and maintained the sysv scripts it would continue to be officially supported, no one did, and that was that.

Re: Interview: Lennart Poettering

#82

Post by digi_owl »

vezzy-fnord wrote: post #66
digi_owl wrote: post #52

The part about Gnome and logind vs consolekit could have been more detailed. Poettering was sitting as co-maintainer of consolekit for some time. Then as logind got underway, the maintenance was to pass to Ubuntu under a new project name. But i can't find any trace of this actually happening. After that the state of consolekit as a project seems to have been in limbo, until recently when a XFCE dev forked the existin…

Oracle actually picked up ConsoleKit and beefed it up significantly for Solaris, giving it true multi-seat support. [1] However, they did this in complete silence, so very few people actually know about this. [1] https://hg.java.net/hg/solaris-desktop~spec-files/file/79574... (15 patches)

Things like this makes me wonder if RH changed once Oracle bought Sun and then forked RHEL into Oracle Linux. Thus Oracle went from being something of a partner to being a competitor, and RH rolled back on various behaviors (package patch sets etc).

Re: Interview: Lennart Poettering

#83

Post by the_why_of_y »

makomk wrote: post #78
_delirium wrote: post #48

Earlier quoted context omitted.

Are there any examples of a process supervisor that isn't also intended to replace the traditional init system? Even systems less ambitious than SMF/launchd/systemd, like daemontools and runit, aim to replace sysvinit, because otherwise you'd have to specify twice , in different ways, how each service should start and stop (though it's possible to set up configurations where that works).

At the moment I'm using OpenRC which does exactly that on top of sysvinit, as are most Gentoo users. You don't have to specify everything twice because init never actually knew how to start and stop services in the first place - with a traditional sysvinit configuration that was all handled by scripts that it started, and OpenRC replaces those scripts.

sysvinit does have built-in service management via inittab(5); unfortunately it is so primitive that in practice it is only used to spawn getty(8).

Re: Interview: Lennart Poettering

#84

Post by JdeBP »

_delirium wrote: post #43
nurb wrote: post #23

"if you do an init system but still invoke all the shell scripts and all the other things needed to bring up the system, you’ve only solved part of the problem." That's exactly what I think is wrong with systemd. If a script bring a speed issue on start up, it should fixed by optimizing the script, use/create another script language with parallelism and higher pref, or even turn it into a compiled program. This is no…

> In fact the only purpose of an init system is to start executables in a defined order, not more. A good init system should also do process supervision and integrate with the OS's resource-management subsystem (on Linux, cgroups). You could do that with an even bigger pile of shell scripts, of course, and some Linux distros towards the end of the sysvinit era have been trying to. But at some point a giant tangle of…

> It's not like systemd is the first system to come to that conclusion, either. [...] Earlier than that, djb also wrote an init replacement called daemontools, [...]

daemontools gained svscan in 1998, and svscanboot in 2001. Years earlier, in AIX version 3.2 released in January 1992, IBM introduced its (then) new System Resource Controller. This was, and still is, a service manager that is spawned by the initial user process, that has the task of supervising daemon processes, bringing them up and down in response to administrative command, logging control activity, and notifying about failures to run.

You'll find things like the srcmstr process; the startsrc, stopsrc, and lssrc commands for starting, stopping, and listing services; the whole notion of signals to control daemons (SIGTERM, SIGNORM, SIGFORCE, et al.); entry 5.2.1 in the Usenet comp.mail.sendmail FAQ which talks about how fork-and-exit-the-main-process by Sendmail breaks service management; all of the "How do I get my too-clever-for-its-own-good daemon to work with this new service management system?" discussions in the mid-1990s; and IBM's documented advice from at least as early as 1995 on how to write daemons properly, achingly familiar.

One can look to mainframe and minicomputer operating systems before that, and also to Windows NT 3.1 which had the initial user process spawning the Service Control Manager, released in 1993. But in the narrow Unix+Linux worldview, credit should go to AIX for being the first operating system released where people had come to that conclusion, approaching a quarter of a century ago.

Re: Interview: Lennart Poettering

#85

Post by JdeBP »

astine wrote: post #64
lawl wrote: post #45

Earlier quoted context omitted.

Process supervising is for process supervisors. Init's jobs is to be able to start a process supervisor.

Then the process supervisor can then launch your processes. But then all init is doing is launching your process supervisor. We can just drop a step by providing the process supervisor executable to the kernel. There is no need for init anymore.

> But then all init is doing is launching your process supervisor.

This "all init does/needs to do" notion is oft-repeated, but it is oft-repeated rubbish. It is a notion commonly held by people who have never actually written a process #1 program that functions in production systems; because experience (as I can attest) teaches otherwise. There are, in fact, several things that various operating system kernels and other programs demand of process #1 that one simply cannot escape. People think that fork()ing things and acting as the parent of orphaned processes is the prime function. Ironically, dealing with orphaned processes is (with recent Linux kernels) a part the system that one can largely factor out of process #1 into other processes, whilst the things that people usually forget in their off-the-top-of-the-head designs for init (such as handling SIGINT, SIGPWR, SIGWINCH, and so forth sent from the kernel and enacting the various system state change requests) are the parts that one cannot. To see what one actually has no choice but to do in process #1 programs, look at the overlaps in the operation of Gerrit Pape's runit, Felix von Leitner's minit, and the system-manager program from the nosh package. There are several things for a /system manager/ to do when there's a separate /service manager/.

Re: Interview: Lennart Poettering

#86

Post by JdeBP »

_delirium wrote: post #48
lawl wrote: post #45

Earlier quoted context omitted.

Process supervising is for process supervisors. Init's jobs is to be able to start a process supervisor.

Are there any examples of a process supervisor that isn't also intended to replace the traditional init system? Even systems less ambitious than SMF/launchd/systemd, like daemontools and runit, aim to replace sysvinit, because otherwise you'd have to specify twice , in different ways, how each service should start and stop (though it's possible to set up configurations where that works).

> Are there any examples of a process supervisor that isn't also intended to replace the traditional init system?

Yes. You are conflating System 5 init and System 5 rc.

The IBM AIX srcmstr program is intended to be run by init, not to replace it. ("The SRC is operationally independent of the init command." - http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com... "You can also start the SRC from the command line, a profile, or a shell script, but there are several reasons for starting it during initialization" - http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com...)

Gerrit Pape's runit has "runit" (exec()ed from "runit-init") as a system manager running as process #1 doing the system management tasks that only process #1 can do, and "runsvdir" as a service manager that runs as some other process.

Daniel J. Bernstein's daemontools, Adam Sampson's freedt, and Bruce Guenter's daemontools-encore do not, strictly speaking (and pace Paul Jarc's patches), have a program for running as process #1. They all have "svscanboot", which is to be spawned by process #1 and which runs "svscan" as a service manager.

Laurent Bercot's s6 does not have a program for running as process #1. Its "s6-svscan" is a service manager, usually run as some other process. And its "s6-svscanboot" sample program is analogous to "svscanboot". It comes with examples for writing one's own program to run as process #1, but "s6 cannot provide live examples without becoming system-specific" (http://skarnet.org./software/s6/s6-svscan-1.html).

Wayne Marshall's perp has "perpd" as the service manager. This can be started by "perpboot", which (like "svscanboot") is spawned by process #1 rather than run as process #1. There's no program in the package for doing process #1 tasks.

nosh has a program for process #1, "system-manager", and a program that runs in another process to do service management, "service-manager".

All of these aim at replacing System 5 rc. Only two in fact offer in-the-box replacements for System 5 init. Do not conflate rc and init. The person that you were replying to was wrong; hence the basis for your question was wrong. Learn from "system-manager"'s manual page, "runit"'s manual page, what Paul Jarc found when he experimented with running svscan as process #1, and indeed "systemd"'s manual page to an extent. "init's job" is more than "starting a process supervisor".

Re: Interview: Lennart Poettering

#87

Post by JdeBP »

the_why_of_y wrote: post #83
makomk wrote: post #78

Earlier quoted context omitted.

At the moment I'm using OpenRC which does exactly that on top of sysvinit, as are most Gentoo users. You don't have to specify everything twice because init never actually knew how to start and stop services in the first place - with a traditional sysvinit configuration that was all handled by scripts that it started, and OpenRC replaces those scripts.

sysvinit does have built-in service management via inittab(5); unfortunately it is so primitive that in practice it is only used to spawn getty(8).

> unfortunately it is so primitive that in practice it is only used to spawn getty(8).

The AIX System Resource Controller is spawned by a record in /etc/inittab. (AIX actually comes with utilities for maintaining /etc/inittab such as mkitab.) So too is svscanboot in daemontools 0.75 and later. Gerrit Pape is currently having problems with the Debian package for running runit, precisely because runit has for some years been run from /etc/inittab in some configurations and in Debian 8 it is suddenly no longer a file whose existence is always guaranteed because it is part of an "essential" package. There are some other packages in Debian 7 that have undocumented dependencies from the existence of an /etc/inittab file, because they too read/write it for their own purposes. I have yet to verify whether they've been fixed for Debian 8.

Don't think for one second that in the second decade of the 21st century people only ever use /etc/inittab for getty. (-:

This is one of the quieter on-going problems for Debian 8. It switches one to using systemd, because that's the Debian 8 default; but there's no upgrade path or compatibility mechanism for /etc/inittab. Every few months, another "I was (unknowingly) using /etc/inittab; I upgraded; it broke." person seems to pop up.

Re: Interview: Lennart Poettering

#88

Post by Argorak »

agumonkey wrote: post #67
Argorak wrote: post #14

Earlier quoted context omitted.

>> Then we convinced the Fedora Technical Committee to adopt it, and then Red Hat internal management accepted it for RHEL, and we managed to convince every committee that mattered, bit by bit. > So there was, in fact, a PR campaign. So, how would you spread a piece of software without convincing people of it? I'm not sure what's bad about it?

It should be interesting to investigate about how other technology shifts happened before. Were they an obvious revelation or the result of lobby/PR/... ?

In doubt: people rooting for them, which comes down to "PR" (for the definition that most hackers use).

Re: Interview: Lennart Poettering

#89

Post by the_why_of_y »

makomk wrote: post #77
chousuke wrote: post #74

Earlier quoted context omitted.

Your second statement misses the point. Your process supervisor can be ultimately stable and never crash, but if it does crash, it's just as fatal as init crashing. systemd PID 1 won't be rendered prone to crashing just because it contains more than trivial amounts of code. If that were the case, then surely the Linux kernel would be crashing every fifteen minutes, considering how much code it contains. As far as I'm…

No, your process supervisor crashing won't be as fatal as init crashing, because init crashing is an instant kernel panic under Linux. Also, very few projects are as robust as the Linux kernel or have development practices that are as good, and systemd is unlikely to be one of them.

When the supervisor crashes, which should occur extremely rarely in any case, the state of which services are running is lost, and its child processes are re-parented to PID1, so when a new instance of the supervisor starts it cannot tell which services are running, and which of the running processes belong to which service. During the time the supervisor needs to re-start (presumably init would respawn it?), some of the running processes could exit without notice.

What is gained by restarting then? You'll likely want to reboot to get the system into a consistent state anyway.

Here is a war story of an embedded developer who actually created his own init system with separate supervisor process, and found that it doesn't actually make the system as a whole more robust:

https://lwn.net/Articles/623527/

For a good disucssion of the trade-offs involved see this comment by JdeBP:

https://news.ycombinator.com/item?id=8384251

Edited to add: Also, is your comment about bad development practices in the systemd project purely based on statistical conjecture (which would mean it applies to every single project, except of course the Linux kernel where presumably you have personally observed the absence of bad practices), or do you have anything to back that up?

Re: Interview: Lennart Poettering

#90

Post by digi_owl »

the_why_of_y wrote: post #89
makomk wrote: post #77

Earlier quoted context omitted.

No, your process supervisor crashing won't be as fatal as init crashing, because init crashing is an instant kernel panic under Linux. Also, very few projects are as robust as the Linux kernel or have development practices that are as good, and systemd is unlikely to be one of them.

When the supervisor crashes, which should occur extremely rarely in any case, the state of which services are running is lost, and its child processes are re-parented to PID1, so when a new instance of the supervisor starts it cannot tell which services are running, and which of the running processes belong to which service. During the time the supervisor needs to re-start (presumably init would respawn it?), some of…

Lovely exchange in those LWN comments about monolithic vs modular. In particularly how the proponents are (perhaps willfully) confusing public and private APIs...
Post reply on HN