Seems to me like yet another systemd two minute hate. It's getting quite tiresome to see.
They then decided that, rather than encapsulate fixes for their breaking change in portable APIs like daemon(3) and PAM to allow user space to keep working as intended, it'd be easier to just outsource the labour onto the community by demanding every user space program that was working just fine do the work of adding a couple of hundred lines of systemd specific code directly, encapsulation be damned.
That's an insult to the tmux developers in particular, and disdainful of Open Source devs in general. Don't show up at my door telling me to do a bunch of work for you to fix your shit. You broke the contract; encapsulate the fix so I don't have to care.
Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance. Think about Chrome having flags to "run background processes after app is closed".
Systemd is trying to maintain backwards compatible behavior by collaborating with developers. We should not do these things cost "that's the way they've always been" is killing innovation.
Correct
> This is no more an insult than removing cgroup write access from processes or any other new kernel feature.
False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money.
> Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance.
There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result
> Think about Chrome having flags to "run background processes after app is closed".
What would stop Chrome from doing that under this new regime? Literally the only difference is that they'd be accomplishing that via systemd-specific code rather than portable, SUS-compliant code.
Ultimately all this change is accomplishing is deprecating simple, portable interfaces for achieving nohup behaviour with baroque, dbus-laden, systemd-specific ones. Red Hat's goal here seems to be little more than increasing systemd's surface area; otherwise, why not simply hide the sausage-making systemd cruft behind the portable API?
> Systemd is trying to maintain backwards compatible behavior by collaborating with developers.
"Collaboration" is not a synonym for "I have altered the user space contract. Pray I do not alter it further".
> We should not do these things cost "that's the way they've always been" is killing innovation.
"Innovation" is not a synonym for "instead of a daemon(3) call, here's 150 lines of dbus crud to get right back to where you were before".
The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped. The new cgroup-based system makes it impossible to evade being reaped by playing games with fork. This mechanism is valuable, but it is possibly not the best default for most systems.
You can't guarantee reaping while allowing for opt-out semantics for things like tmux. Everyone who thinks that's some innovation being achieved here is misunderstanding it.
This is originally about some GNOME daemons sticking around when they shouldn't. GNOME should just fix that, of course, but it points to the hole of it being all-or-nothing when it comes to nohup'ing. There's no good mechanism for asking for more limited lifetimes.
Of course, the Right way to solve that would be to leave the existing API alone for the all/infinite lifetime case, float a proposal for a new API for the limited case, raise consensus, implement it, and encourage devs like GNOME to move to the new limited case.
But that might mean actually talking to the community and building an encapsulated API that could be reimplemented on other platforms. So much easier to break everything and demand the world keep up, with the added benefit of all those raw dbus calls and hard-coded end points making portability off of your 2 billion dollar cash-cow OS just a bit incrementally harder, again.
And this is a red herring. If the process is malicious, it can just as well use this systemd method to keep from being killed and continue to do its dastardly deeds in the background. Logically, this "feature" can not be about controlling purposely malicious programs, because there's no way to determine if a process is malicious or not just by asking it or by having it assert that it is not. The only reason this exists is to paper over bugs in either the way these daemons are spawned (ssh-agent and pgp-agent, for example, work best when they appear in the execution inheritance hierarchy, rather than as separately spawned programs that run as siblings) or in the way they detect that a session has ended.
Isn't the usual answer to this, "If you don't like it, fork it?"
If you work on a large FOSS project, you will spend a lot of your time reacting to decisions made by other people. You won't agree with all of them. Some of those decisions will be made by $2B companies, some of them will be made by influential individuals like Linus and Lennart. Still others were made 20 years ago by some anonymous person in their basement.
Either way, if your complaints fall on deaf ears, your options are limited to living with it or forking it. That's just how it works.
It does seem like what is being requested is not a sensible change, but arguing with insults and getting so personal seems like poking a rather large bear with a very short stick because it is trying to make you move away from it even though you were there first. You can do that, but it's unlikely you will enjoy the outcome.
Zbigniew Jędrzejewski-Szmek, systemd developer, is asking for tmux to change to incorporate some systemd-specific Desktop Bus code. Nicholas Marriott, tmux developer, replies that this should go in the GNU libc daemon() function for everyone whose programs do this to benefit, repeating what he said 5 years ago.
Following your model, which should Zbigniew Jędrzejewski-Szmek be forking? tmux? Or GNU libc?
five years ago:
I'm not wildly happy about adding more OS-specific code to tmux for something it already does perfectly well everywhere (including Linux right now).
If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux?
There doesn't seem to be any discussion following these additional questions from the tmux side. So what you're really saying is that systemd has been aware of the architectural issues with their design for five years, yet have not bothered to fix their end?
tmux dev asks:
> If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux?
Which is a perfectly sensible question. After all, what value is there in the systemd team being so resistant to maintaining user space contracts? What technical gain is there in pushing low-level systemd dependencies high up into user space? Wouldn't sane engineering be to encapsulate this kind of low-level platform detail behind libc interfaces like daemon(3), which exist precisely to abstract away this platform-specific knowledge? If the daemon(3) infinite lifetime semantics aren't desirable in all cases, why not add a second call, say user_daemon(3), to address those cases without breaking everyone else?
Zero response from the systemd devs, and 5 years later they change the default to break everyone without following up on these obvious critiques of their design.
If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!"
They can't win. Haters gonna hate.
This critique makes zero sense. Encapsulating this kind of thing is exactly what libc is for. What daemon(3) has to do to achieve it's semantics varies by platform. daemon(3) abstracts that away. That's the point of it. Ditto everything else in libc.
Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job.
> If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!"
Again, you seem to not understand the concept of libc and its abstractions.
THere's nothing Systemd-specific about the idea of a user_daemon(3) call. On systemd-using systems it could be implemented using systemd-specific code, whereas on other platforms it could be implemented via OpenBSD specific code or FreeBSD specific code, etc. It could simply be a pass-through to daemon(3) on platforms that don't care about limiting the lifetime of some but not all daemons.
That's what libc is for. It exists to hide the low-level details of the platform from user-space.
Circulating a proposal to extend libc with a new call is exactly what you'd expect from a good citizen in the Open Source community. From a user-space developer's perspective, abstracting away hundreds of lines of dbus calls to systemd-specific endpoints is unequivocally The Right Choice.
That Red Hat seeks instead to push the systemd dependencies as high into user space as possible suggests that technical concerns are not their primary motivation, because Big Ball of Mud style of engineering is bad from any perspective.
> They can't win. Haters gonna hate.
It's reasonably clear that you simply don't understand the critiques being presented here.
Unless those system specific things are systemd specific things, then all people do is complain.
A reply to one of my other comments:
> Systemd is not a platform. And not every Linux runs systemd.
Another reply:
> Didn't know linux also means systemd.
You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though.
> There's nothing Systemd-specific about the idea of a user_daemon(3) call
True, but as soon as a systemd developer proposed adding user_daemon it would immediately become a "systemd" function. As soon as they propose modifying daemon to work with systemd, systemd would be accused of trying to take over libc.
One of the BSDs could modify daemon and no one would bat an eye, apparently OS X did so to play nice with launchd. But "linux is not systemd", so they can't win.
> Unless those system specific things are systemd specific things, then all people do is complain.
According to you. Although, again, I continue to assert that most people understand that libc is the correct place for this.
>A reply to one of my other comments:
>> Systemd is not a platform. And not every Linux runs systemd.
>Another reply:
>> Didn't know linux also means systemd.
> You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though.
Again, libc is not a homogenous library. glibc need not be implemented the same on all linux systems. Implementing daemon(3) semantics could be done either via systemd or not, as makes most sense on a given linux platform. glibc already does this for other things. The criticism that this makes or assumes all of linux == systemd doesn't apply.
Either way, we'll never know, because the systemd devs did not even bother to try being good actors, here. They're ignoring libc entirely in favor of pushing systemd dependencies up the stack.
edit: I want to take this a little bit farther:
The idea that systemd devs have to push a bad engineering decision (to tightly couple low-level platform details) onto upstream code with no abstractions, which they are being heavily criticized for, was somehow necessary to avoid misguided criticism they might have received for trying to do this the right way, is simply a wrong argument that doesn't make sense.
Systemd developer asks libc to add systemd specific code
I think you should check what "backwards compatibility" means, because it's the total opposite of what you're describing
Not just tmux, every opensource project that used established nohup practices. For example, now all of my virtualbox instances are killed when I logout of Gnome on rawhide. This was a feature of virtualbox that’s worked perfectly for years now.
Obviously Red Hat's behaviour in general shows disdain for any devs in any project who had working daemonization code that just got broken.
"Hey, can you implement and maintain new platform-specific code to work around this problem we're going to introduce by breaking behaviour of programs using a 21-year-old API?"
It feels especially egregious because, as commenters pointed out, implementing the PAM API is a better (and undoubtedly more portable) way to do this that the developers of systemd didn't seem to consider. Instead, they jumped straight to "implement a custom fix just for us so our breaking change doesn't break your app too".
I wouldn't consider that bit to be particularly egregious. The thought process of a systemd developer confronted with a regression caused by systemd changing some well-known behaviour would naturally lead to a solution where program X tells systemd that it needs to be handled differently. It's basically a version of the anecdote that experienced developers aren't better because they know the answer to every question, but rather that they know which question to ask. Apparently the discussion has lead to a better solution (not that I would be a good judge of that), so this seems like a bit of a storm in a teacup.
They already released systemd 230 with this behavior and the bug reports from users of unstable/rawhide sparked the "public" discussion. (The bug report in the link says this right, but it still comes a week after the release instead of before)
Seriously, every single person who feels compelled to offer their opinion based on what is an emotional response to Lennart's (or anyone's) "overreach/arrogance" is contributing little more than noise to the whole process. It's far too easy for someone who doesn't interact face-to-face with someone else to fall in a trap of assuming the worst about another person when there's a technical disagreement; this is a form of cognitive bias that pollutes development in the corporate world all the time. I'm as guilty of it as anyone, and I've learned to be wary of the temptation to project bad qualities on other people who I disagree with but don't interact with directly.
In the open source world it's so much worse though- not only do almost all developers interact indirectly (i.e. not face-to-face), but there are potentially thousands of people who are basically just casual observers who want to jump in to give their 2 cents. That's great! But it's only great as long as those 2 cents aren't just people bikeshedding, or actively trying to make things personal rather than technical. Unfortunately, more often than not it is bikeshedding, and literally the only thing they have to bikeshed about is to try to make it personal. :(
Instead they should take a step back and rethink their proposed solution every time they get strong feedback or face some resistance from the open source community.
So now not only have we not achieved that goal, but now we've inserted an additional layer of complexity into the mix.
It's an entire middleware layer that sits between userland and the kernel that we did not have before.
The distinction being?
Edit: I'm out of my HN comment quota but kind of glad I am. Because I'm clearly not going to get anything productive from a thread where I wonder aloud why systemd is classified differently and where that distinction lies. When does an init system become middleware "that we didn't have before?" I can think of a few answers but was curious what others think. Fuck me, right?
Instead, ask a question, get snarkily called obtuse and downvoted because we have the misfortune of systemd being the topic of conversation. History shows us you might as well not even participate; if all the people who argued about systemd invested that time into productive activities we'd have warp drive by now. Which would be useful to flee systemd threads.
I swear, systemd is tech's abortion debate.
For years people have been locking their keys in their car and then having a locksmith open the door when they get back. Now, someone is trying to improve the locks so that a locksmith cant open the door and people are complaining that it ruins a perfectly good arrangement.
In this analogy, 'locking the keys in the car' is 'logging out' and the locksmith is 'nohup'.
systemd isn't really out to break nohup, they are trying to fix the logging out process. Sure, nohup has worked for decades, but 'logout' has never worked right.
The problem is that 'nohup' is designed to 'run a command immune to hangups' not 'run a command even after I logout' and there has never been a distinction between an individual connection 'hangup' and a full user 'logout'. With systemd, there is, and programs don't handle the distinction.
If you don't think there should be a distinction KillUserProcesses can be turned off.
This is an example of one of the concerns people had -- and were told to stop spreading FUD -- about systemd in that it seriously overstepped the bounds and desires of an init system.
Killing user processes after logout (when they have been set to not do so, through nohup usually) is not sensible.
Edit: clarification
In other words, if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided and we'd all be happier, but since it didn't the systemd guys are trying to implement it retroactively, which is going to break a lot more stuff than tmux/screen/etc.
Only if you can succesfully determine which ones the user wants to keep running. Otherwise it's just breaking stuff, as this story shows.
if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided
Not really. You will always have sub-standard software that doesn't adhere to the system's declared semantics, and just goes by "what works" (ask the WineHQ guys). Any API that has been around for 21 years will have corner cases where software just breaks. That does not mean you're then free to break the old API yourself.
edit: If you're already using a specific command to tell the application to stay alive (e.g. nohup), you can use the "new" systemd command as well. nohup never related to a "session" scope because that didn't really exist before systemd. A new command _does_ break historical behaviour, but thanks god we do that from time to time. That's how innovation works.
How is it so? I cannot see a single legitimate justification for such a stupid behaviour.
> "session" scope
Exactly. There is no such a thing, and it should not exist, it's a totally alien concept to anything Unix.
(By the way, I disagree with this request to change tmux)
Not after "logout", but after terminal is detached. For whatever reason. There is no such a thing as "logout".
When I log off (by giving the logout command) the shell will print ‘logout’ and
execute commands from the file ‘.logout’ if it exists in my home directory. After
that the shell will terminate and UNIX will log me off the system.
The concept is commonly called logout, even if you prefer to call it something else.
If you had two logged-in terminals on your desk and ran 'logout' on one of them, are you still logged in?
Dbus devs apparently asked themselves the same, added the concept of a user session to dbus alongside the existing login session.
Gnome code happens to get the two confused (or dbus fails to properly tell one form the other, likely by mixing old and new behavior).
Systemd dev notices leftover Gnome processes, and convince Poettering to flip the safety on the big gun.
All this while giving crap all about unix conventions...
... with nohup. Which now doesn't work.
(Added:) The first runtime, in systemd parlance (I think), would be the session scope, the second runtime would be the user service and the third... well, something different, as you'd pass on things (group memberships, environment variables, namespaces) from your shell/session into a long-lasting service. One probably would want to extend the "once the last of my session has ended" state to the runtime of the "run forever" command.
Most non-technical users, I guess, would really prefer one of the first two lifetimes to be the default. As being able to start from a clean state after logging in- and out is rather convenient.
As nohup, in an interactive shell, is used for the third "keep running forever" option, I think it would be reasonable for distributions to alias it to the relevant "systemd-run..." command for all default shells. Then user-expectations would be perfectly met (and scripts will still run the binary /usr/bin/nohup).
Progress is building upon the best practices of the past, not breaking things because a bunch of very low quality, uneducated "developers" who all came from an alien culture simply could not think of a better, idiomatic solution.
This is the level of discourse I've come to expect from any discussion related to systemd
> and no, unix signals are not a sane API
It might not be modern, but it's stable, widely used, and incredibly well documented. Hell, systemd is implementing this behavior using signals.
> Breaking with historical behavior is called progress.
It's not historical behavior when applications are today being developed that rely on said behavior.
I think the problem people have is that systemd developers seem to actually believe this axiom.
What you are describing is systemd becoming a kernel sitting on top of a kernel, second guessing the actual kernel.
Seeing such an emotional reaction so long after the war makes me wonder if systemd can survive in the long run, though.
Seems to be an issue of "The north remembers."
Requesting the specific desired feature/fix is almost always preferable.