Systemd, ten years later: a historical and technical retrospective • Hacker News Board

Re: Systemd, ten years later: a historical and technical retrospective

#271

Post by pas » Mon, May 04, 2020, 10:34 AM UTC

zozbot234 wrote: post #29

ttctciyf wrote: post #9

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to per…

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…

No, it has nothing to do with remote and such.

systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup.

cgroups are control groups, you know, to control processes. Which was simply missing for decades in Linux.

nohup should be enhanced to support systemd, or systemd should provide a nohup wrapper, and just start a new scope (cgroup) for whatever the user launches with nohup.

...

Now, that said, I have no idea why distros and systemd did what they did without much communication, but ... that's usually the Linux way :/

Re: Systemd, ten years later: a historical and technical retrospective

#272

Post by vezzy-fnord » Mon, May 04, 2020, 10:34 AM UTC

cycloptic wrote: post #267

vezzy-fnord wrote: post #178

Earlier quoted context omitted.

The problem with this straightforward thesis is twofold: firstly, distribution developers did not have any coherent position on the disadvantages of sysvinit or initscripts; secondly, the problem was mostly an iatrogenic one, as the very attempts to 'solve' or 'reform' it made things even less sustainable. When it comes to Upstart, it was almost never used except as a wrapper around initscripts. Effectively you boote…

The distro has historically always been the place that gets pointed at because they are the ones who distribute to end users. No system-level component is going to change this, ever. I am also confused why you're complaining about the job model and all its churn and conceptual problems when the whole point is that systemd was offering to handle that for the distros, which is exactly what they did and are continuing t…

The 'job model' is the wrong abstraction, as is the unit concept which tries to reduce things that have irreducible differences. I'm also rather amused how you're conceding that they're doing a "bad job," but still shrug it off as better than nothing. If you're offering a mediocre solution to an "impossibly large scope" of a task, then you ought to rethink things. Even then, a poorly implemented feature can be worse than none at all.

So far as prior art is concerned, see my old post: https://blog.darknedgy.net/technology/2015/09/05/0/

I would also point out OpenWrt's procd as an example of how to have hotplug-capable service management at a fraction of the complexity: https://openwrt.org/docs/techref/procd

Now, this rethinking did indeed come with HAL, when the idea of a master daemon and ad-hoc service manager reacting to hardware state changes was unanimously rejected by the Linux patriciate as wrong. Perhaps with systemd they will one day reach the same epiphany for system and user services. Either way, I'm not terribly personally invested in this anymore -- I just figured I'd wrap my thoughts up on an issue that occupied a good deal of my time years ago.

EDIT: As to B, the problem of process supervision and having an idiomatic way of daemonizing has been solved for a long time: https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.ht...

Re: Systemd, ten years later: a historical and technical retrospective

#273

Post by rcxdude » Mon, May 04, 2020, 10:38 AM UTC

kelnos wrote: post #208

josteink wrote: post #167

Earlier quoted context omitted.

Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.

I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.

The implementation of a correct version of the above in sysvinit is no less complex, especially in its emergent behaviour.

Re: Systemd, ten years later: a historical and technical retrospective

#274

Post by majewsky » Mon, May 04, 2020, 10:42 AM UTC

dTal wrote: post #266

lorenzhs wrote: post #242

Earlier quoted context omitted.

That's a dishonest argument and you know it. The entire home directories thing is aimed at enterprises, and nobody wants to enable it for individuals' machines. Poettering said as much in the talk where he presented it. It would be much more reasonable to respond to people who dislike systemd if they wouldn't constantly make bad-faith dishonest claims about it.

The question remains, what do home directories have to do with init, at all? Okay so Poettering wants to "fix" home directories - is there any reason to couple that with systemd, beyond the fact that systemd is his baby (and point of leverage over the rest of the system)? There are dozens of other examples - network configuration? syslog? cron? This is what I mean by 'OS middleware' - systemd is basically a distro, a…

That's one shitty conspiracy. If this were Red Hat's play, why would they do it with a project that other distros can adopt and have adopted? If anything, providing APIs in systemd makes it easier to migrate to other distros as long as they use systemd. (All relevant enterprise distributions use systemd, i.e. RHEL and SLES and Ubuntu Server.)

Re: Systemd, ten years later: a historical and technical retrospective

#275

Post by whereistimbo » Mon, May 04, 2020, 10:48 AM UTC

vezzy-fnord wrote: post #160

whereistimbo wrote: post #41

vezzy-fnord! I have always enjoyed your commentary and perspective of operating system, it's nice to see you back again!

> it's nice to see you back again! Not for long, probably. I drifted out of this sphere years ago, and came back specifically for systemd's 10 year anniversary, as I felt obligated to at least do that. Judging by the tone of the comments, 10 years later is still too soon to discuss systemd dispassionately, but when I come back in 10 more years I'll see if things have changed.

Would you like to tell me what OS are you currently using? Are you still keeping pace on OS research?

Re: Systemd, ten years later: a historical and technical retrospective

#276

Post by voldacar » Mon, May 04, 2020, 10:51 AM UTC

theamk wrote: post #127

gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B…

The parent comment is criticizing systemd, not upholding the virtues of sysvinit. There are more than two init systems out there, and it is possible for sysvinit and systemd to both be bad in their own ways

Re: Systemd, ten years later: a historical and technical retrospective

#277

Post by throw0101a » Mon, May 04, 2020, 10:51 AM UTC

Spivak wrote: post #66

throw0101a wrote: post #35

Earlier quoted context omitted.

Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.

I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gon…

> It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.”

It may be a good default if you're starting from scratch, but GNU Screen has came out in 1987. (Poettering was 7 years old then.)

> This is basically the same behavior as Windows […]

Comparing it to Windows' behaviour is not going to win you any positive points with me. :)

> This is a feature that sysadmins have been asking for.

As a sysadmin this breaks my own daily workflow. I have 400 VMs that are treated as pets and I probably screen sessions on at least a third of them. (I have another 500 that are cattle-like.)

> And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.

Aka, malicious compliance. See also: nowhere does it say that the US President cannot fire the FBI Director. Also: nowhere does it say that the US Senate has to hold hearings when a US President nominates a judge for the US Supreme Court.

Re: Systemd, ten years later: a historical and technical retrospective

#278

Post by cycloptic » Mon, May 04, 2020, 10:51 AM UTC

vezzy-fnord wrote: post #272

cycloptic wrote: post #267

Earlier quoted context omitted.

The distro has historically always been the place that gets pointed at because they are the ones who distribute to end users. No system-level component is going to change this, ever. I am also confused why you're complaining about the job model and all its churn and conceptual problems when the whole point is that systemd was offering to handle that for the distros, which is exactly what they did and are continuing t…

The 'job model' is the wrong abstraction, as is the unit concept which tries to reduce things that have irreducible differences. I'm also rather amused how you're conceding that they're doing a "bad job," but still shrug it off as better than nothing. If you're offering a mediocre solution to an "impossibly large scope" of a task, then you ought to rethink things. Even then, a poorly implemented feature can be worse…

The entire purpose of designing models is to reduce things that have irreducible differences and then tell people to shut up and deal with it. There is nothing else there. What is it exactly that you think IT gets paid to do other than this? We have finite time on this planet.

Also, things are constantly being rethought. That is quite literally what the churn encompasses. You can't complain about this while asking for it at the same time. I have seen all these lists of other init systems and while they are interesting, they are completely missing where the actual discussions are happening and what is actually being discussed. The core problem has already moved to a different area and that's why it really doesn't matter if they are doing a bad job. I can see you hinting at this in your article but it's not good to dwell so much on things that happened in the past and are already history. I am very grateful that you actually quoted all your sources though, so thank you for that.

The comparison of init to HAL seems not relevant to me; if anything that has made it obvious that they had the right idea but it was in the wrong place, and that init was the right place to put this type of logic after all. Adding to that it also seems very unlikely that the kernel developers will change their position on the responsibilities of an init any time soon.

And about the idiomatic way to daemonize, nobody follows those guides. Nobody. Seriously. It's a complete clusterfuck and writing more guides doesn't help either. There are an absurd number of programs out there that still use pidfiles. Go and do a search on github for "pidfile" and be horrified.

Re: Systemd, ten years later: a historical and technical retrospective

#279

Post by majewsky » Mon, May 04, 2020, 10:53 AM UTC

oconnor663 wrote: post #98

ttctciyf wrote: post #9

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to per…

Have you tried `sudo loginctl enable-linger [username]`? This used to be well-documented, but I don't see much about it now. It's possible things have changed since the last time I had to deal with this?

What do you mean? I still see it in `man loginctl`.

> enable-linger [USER...], disable-linger [USER...]

> Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller. See also KillUserProcesses= setting in logind.conf(5).

Re: Systemd, ten years later: a historical and technical retrospective

#280

Post by throw0101a » Mon, May 04, 2020, 10:55 AM UTC

mbreese wrote: post #84

dooglius wrote: post #36

Earlier quoted context omitted.

Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.

I don’t know if these even exist anymore, but I’m imagining a class that meets in a room of workstations. Students can login to any workstation in the room. In this kind of shared environment, you may not want to have a student start a screen session and use the resources of a workstation when they logout. They could be sucking up cpu time from the next person to log in (from the next class). It’s a scenario that mig…

> It’s a scenario that might make sense here.

Perhaps. I have worked half my career in academia & research, going back to when Solaris (SPARC) workstations were a thing, and this was never a problem.