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

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

61–70 of 458 posts

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

#61

Post by MereInterest »

yawaramin wrote: post #33
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…

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.

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

#62

Post by hedora »

yawaramin wrote: post #33
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…

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

Why should I be forced to prepend all of that to every command I want to survive terminal hang ups? The old mechanism was more user friendly, and better documented.

It’s just another example of systemd making everything on the system worse.

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

#63

Post by hedora »

ttctciyf wrote: post #20
gerdesj wrote: post #16

Earlier quoted context omitted.

Screen still works. I use it all the time. Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link you provide is absolutely huge and from three years ago. Please give me a simple "stages to reproduce ..." style report. Please keep it simple and short and I'll fill in the blanks if I can and only trouble you for stuff I'm too daft to work out.

To answer your question: remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) - there is no screen session because it was killed by systemd immediately after log out. (syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing process 3290 (screen) with signal SIGTERM. ) But that's hardly the point, the point is the toxic "you're doing it wrong" mentality that infest…

Based on one of the sibling comments, if you modify screen to add a runtime dependency on systemd, the problem will go away.

I agree this is totally unacceptable, and that the inevitable tone deaf response to such complaints is also unacceptable.

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

#64

Post by nisa »

acdha wrote: post #5

I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to…

> It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to the question of how open-source projects work.

I've read it more as a quirky history writup with some technical and idiology discussions.

FWIW I still think the technical criticism in the article has a lot of merit and what seems "turgid" to you is a nice link collection to learn about systemd minutiae...

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

#65

Post by dralley »

hedora wrote: post #59
gens wrote: post #56

Earlier quoted context omitted.

udev was the biggest step towards "dynamic systems". Or should i say "hotplug" was, since it is more or less the same thing. I completely agree that the init should be an event based system. I'm not arguing that. I never argued that. I did not in fact argue much other then the statement that nobody should say their opinion about anything. You say i left out stuff. I did. A lot more stuff then you wrote here. It would…

Wasn’t the debian vote stacked by a bunch of Canonical employees that voted on party lines, since Ubuntu had already decided on systemd?

I thought it was exactly the opposite, that Canonical employees were fighting for Upstart and Ubuntu only switched to systemd after losing the war in Debian-land.

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

#66

Post by Spivak »

throw0101a wrote: post #35
cmeacham98 wrote: post #32

Earlier quoted context omitted.

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

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 gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner.

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

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

#67

Post by [deleted] »

throw0101a wrote: post #35
cmeacham98 wrote: post #32

Earlier quoted context omitted.

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

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

[deleted]

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

#68

Post by [deleted] »

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…

[deleted]

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

#69

Post by ttctciyf »

yawaramin wrote: post #33
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…

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

Nope:

[user]@[host]:~$ systemd-run --scope --user screen

Job for run-r0b2a43d19a564e2c9f36b5c9b934420f.scope failed.

See "systemctl status run-r0b2a43d19a564e2c9f36b5c9b934420f.scope" and "journalctl -xe" for details.

[user]@[host]$ journalctl -xe | cat

May 04 03:02:54 [host] systemd[918]: Failed to start /usr/bin/screen.

-- Subject: Unit UNIT has failed

-- Defined-By: systemd

-- Support: http://www.ubuntu.com/support

--

-- Unit UNIT has failed.

--

-- The result is RESULT.

May 04 03:02:54 [host] polkitd(authority=local)[879]:

Unregistered Authentication Agent for unix-process:1504:595444 (system bus name :1.25, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus)

----------------------------

I changed my user and hostname to "[user]" and "[host]" respectively, the rest is verbatim.

It's interesting to note that to even see the error report (such as it is) I'm instructed to invoke a special command rather than just look at logs where I might expect to find it, and that when I do so I am locked into some dysfunctional pager requiring me to pipe through "useless cat" in order to cut and paste the uninformative details on long lines.

While the consistent boorishness of my systemd install continues to amuse, the details of this issue and the fact of its resolvability or otherwise by invoking recondite special systemd functionality are beside the point.

Why should I need to know how to run normal and trusted software in special systemd compatible ways that I've previously had no issues with for decades?

As I opine below, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.

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

#70

Post by Spivak »

dooglius wrote: post #36
cmeacham98 wrote: post #32

Earlier quoted context omitted.

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

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.

You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job.

Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.

Post reply on HN