Hacker News new | past | comments | ask | show | jobs | submit login

Salient comment: "Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is: In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly. fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly."

Wait are you saying we should rely on processes behaving nicely? That's not how you design a robust system. It's why we have pre-emptive multitasking, not co-operative. And why mobile OSes sandbox applications rather than trusting them to be good.

Not that we should rely on processes to behave nicely, but that we shouldn't break processes which are because of some which aren't.

In particular, if Gnome is starting a ton of background processes that stick around and cause problems, then the fix should be to change Gnome, not to change the default behaviour and break everyone else.

To use the OS sandbox example, this is the reason why OS X added application sandboxing and forced Mac App Store apps to use it, and not anyone else. Systemd's approach is like Apple saying "We're going to start sandboxing everyone's apps, App Store or no, unless you make these changes to your apps.

Systemd is the hammer and the problem looks like a nail to the systemd developers.

In this case systemd seems to be reinventing process groups, in a totally different way, instead of fixing whatever the reason is why GUI sessions don't use session leaders.

So it's pretty obvious there really is a problem that needs to be fixed, and apparently so far nobody else has made a real or successful attempt to do so.

SIP seemed like an overture in that direction.

I think you're missing the point. Systemd is papering over bugs in other software, and in doing so manages to break unrelated applications.

No, we shouldn't need to rely on processes behaving nicely. But when a program is broken, you fix that program, not change the entire system's semantics.

Not to mention that, with a new interface to keep things running after logout, nothing is going to stop something else misusing that, either purposely or accidentally, to remain running, and we end up right back where we started.

Interestingly enough, none of the bugs in other software that is being papered over are in closed source, so it's not like the original issues are unaddressable in the most direct way possible.

I'm not sure I understand, but it seems that systemd is correctly killing processes when the session ends. and that shell managers like screen and tmux had hacks to make them survive sessions ends in the past (remember when you had to use nohup screen?). they seem to simply have asked for tmux to add their flavor of nohup to the start up check too.

It depends on what you mean by 'correctly'.

Processes using daemon(3) have been around for 21 years, and are used to certain behaviour. Some of those processes behave badly.

systemd is adding functionality to kill all of a user's process when the session ends, no matter what. The problem is that they don't have any way of telling which processes are behaving badly and which ones aren't, so they're telling everyone (e.g. tmux, screen, etc) that they have to implement changes or they'll be killed too.

Fundamentally, the problem isn't whether the systemd behaviour is right, the problem is that it's a huge breaking change and they're asking everyone else to work around the shortcomings of their approach.

> shell managers like screen and tmux had hacks to make them survive sessions ends in the past

tmux, screen, etc. didn't have hacks to survive sessions; they just did, automatically, because of how things worked. systemd is asking the to add hacks to make them survive session ends from now on, when running specifically on Linux under systemd 230+, because systemd is going to change default behaviour for other people's processes.

> systemd is adding functionality to kill all of a user's process when the session ends

They actually added the functionality over 5 years ago. Which is when the tmux project was approached to accept a patch to support pam (not systemd) in order to not be killed.


All they did recently was try to change the default configuration to enable the feature by default.

... as well as, as pointed out twice on this page, not answer in all those years the question that Nicholas Marriott posed about why they are not pushing this at GNU libc, so that everyone can benefit from a better daemon() function that escapes the systemd login session as well as the kernel's login session.

> Shouldn't this code be part of glibc instead of tmux? -- Nicholas Marriott, 2011

> If you want to change how processes daemonize, why don't you change how daemon() is implemented [...] ? -- Nicholas Marriott, 2016

* https://news.ycombinator.com/item?id=11798173

* https://news.ycombinator.com/item?id=11798328

Tomorrows systemd hate post:

Systemd developer asks libc to add systemd specific code

That's just unfounded silliness. There's no reason to suppose that, and plenty of reason (given that they've actually had systemd-specific stuff, such as subreapers, fairly uncontroversially put into the kernel in years gone past) not to.

It may be silly, but I think there is plenty of reason to think that if systemd developers proposed adding systemd support to daemon(3) there would be an even larger negative response.

This whole comment thread is about an optional feature that has existed for 5 years and only recently had its default value changed. You are not affected unless you are running a bleeding edge distribution that has already upgraded to a version of systemd released 5 days ago.

I don't think a more long term solution will present itself in the near future and most likely what will happen is that the default will get changed back to disabled.

This feature has its place in some cases. For example, a public terminal that wants to make sure that users didn't leave anything running. I'm fine with this feature existing. I'm not okay with it becoming the default option. Changing the default behavior implies some endorsement of it for general use, not just in special cases.

I would suggest you learn something about Unix before spousing such opinions, because I don't know where to even begin

nohup is not a hack

What systemd is offering has nothing to do with nohup, it's not "a flavour" of nohup it's a completely different thing

Systemd is not correctly killing processes, this was NEVER DONE LIKE THIS, they decided this out of a whim because apparently Gnome can't do the right thing (how surprising)

Heh--it's like nohup(/daemom), except you make a SOAP call through some middleware to beg some more middleware for mercy so you can do the thing your user asked you to do, because everyone's being punished for a few programs' poor use of the old, more portable API. (I exaggerate, slightly.)

I'm not looking forward to what comes next when Gnome breaks through the new system.

I prefer to keep the mystery and not know all about my opinions from the start. It's the small discoveries that keep the flame of love alight in our marriage.

I do not want systemd to kill processes that have invoked daemon() on session termination. If I wanted it to be killed when I logged out, I wouldn't have invoked daemon()!

When the process is as baked in as systemd wants to be, you have literally no choice but to rely on it behaving nicely. And unfortunately it mirrors the attitude of its developers/sponsors.

I don't understand why Redhat is continuing to sponsor work that is desktop focussed and toxic or even flat out breaking the server environment. The latter is their bread and butter. I get that you want to make the desktop a better experience, but you don't do that by breaking your revenue stream and affecting everyone outside your company too that gets lumbered with your stack.

Robust process management is even more important in server environments. As a sysadmin, systemd is very very useful in my job and it's the building block of things like CoreOS and the like.

This wording, which appears frequently in defense of whatever changes systemd forces on the Linux ecosystem as a whole, implies that systemd is some kind of savior providing features that are neither offered nor considered anywhere else.

As a sysadmin for over 20 years, systemd offers nothing significantly new or different in the areas of process management than any of the other methods to do so, most of which are less intrusive.

A single tool providing a building block for an isolated, specific project says nothing about the general applicability or desirablity of that tool to the wider ecosystem.

Less intrusive and play better with other systems, because they don't believe that they are The Way, The Truth and The Life.

And this is where I'm most uncomfortable with so many of the ways systemd wants things to be done. So much of what systemd provides could have been done with minimal changes to init and by offering better alternatives than what was there. Uptake might have been slower as people learn, over time, where the new system offers something better. It's not offered as "hey, here's a different way to think about things that you might like, give a try!", it's offered as "everything else is broken, and you need to do it this way right now in order!".

Except, you've got people squabbling over their tiny patches of turf and hurt feelings instead To me systemd is determined to unfuck linux, despite it screaming and kicking. Yes, it does some stuff that is questionable, but if it wasn't religiously hated just because it dares to step on "someones" turf...

People bitch about PulseAudio still and it was what made the fucking sound plug and play instead of massive mess

Taking the position that linux needs to be unfucked is saying that it was/is fucked, and that systemd is the Savior that will unfuck it. Many people don't beleive that. But that they don't beleive linux is fucked doesn't mean they think it is perfect, because they know nothing can be. And while it is worthwhile to still strive for perfection, you don't do that by shitting all over what people know, their experience, blaming them for problems they didn't create, and making them do extra work. Especially when they are volunteers.

> People bitch about PulseAudio still and it was what made the fucking sound plug and play instead of massive mess

PulseAudio is still a massive mess. It solved a tiny subset of surface level problems, eventually, and introduced a whole crap load of other ones in the process.

PulseAudio has been around, what, 10 years now, give or take? I think I've only stopped having to fight with it in the last couple of years. When it first landed it was by no means an improvement from OSS, and it took a while until it could realistically compete. It brought a bunch of advantages with it, but it was far from easy.

If you want to see a fun example of how annoying PulseAudio can still be, try and make a linux machine act as a bluetooth audio receiver. It takes only a couple of minutes work installing and configuring the bluetooth side of things. The PulseAudio side of things will suck up hours of your time trying to persuade it to be consistent, running through a godawful series of inconsistent command lines.

It's pretty clear that systemd is determined to unfuck the linux desktop experience. They're not solving problems that exist on the server side. When you look at the justifications for various bits of really breaking stuff, it's almost always (as in this case) coming down to something related to the desktop experience. They've futzed about with stuff, breaking things along the way, because it "speeds up boot." How often do you reboot your servers, and does it really matter that it's 20 seconds quicker?

The goal is admirable (The linux desktop can be a crappy experience, I've been using it as my primary work environment for pushing on 10 years now, and using it in general for closer to 15.) The methodology is not, nor is the attitude of the developers. They continue to approach problems from the perspective of "we know best", "not invented here" and "The only fix is a ground up re-write". Along the way they're making the exact same mistakes existing stable and mature software made decades ago. Worse, they're breaking things that really shouldn't be broken and they're betraying a complete lack of understanding about how linux is run in production environments. This particular case is a perfect example. They've decided that processes should be reaped on all systems, in all environments, when users log off. Not because this was a particular problem anywhere, but because some processes weren't being cleanly stopped when someone logged out of Gnome. It's fixing a minor desktop issue, something that doesn't affect the large majority of the user base, in a fashion that breaks what a large majority of the people actually do.

Here's another classic example: http://www.spinics.net/lists/netdev/msg365477.html systemd developers decided that the way IPv6 route advertisement was processed in the kernel was wrong (despite having been fully functional and stable for a long, long time), and decided that they really should do it themselves in an incorrect fashion.

At its core, the *nix environments core strength has always been that it's composable, focusing on complect over complex behaviour, creating a cohesive whole out of individual and specialised components that have specific tasks. You take a similar when writing software applications. Just as with writing software and using libraries, you use the ones that meet your requirements the best. This flexibility allows people to build platforms and infrastructure that does what they need, and allows people to solve issues developers couldn't have anticipated in the first place.

Systemd's approach is instead a highly opinionated and inflexible "this is the way things will be". It's likely a perfect approach for a desktop environment, but that's not where it's being restricted to. The primary consuming environment is servers where they're 'fixing' things that weren't broken there in the first place.

You will see a certain subset of server admins praising them thought. The new breed of *aaS admins that are used to spinning up 1000+ containers/VMs with the press of a button.

To them systemd is golden, as you can see with how CoreOS is basically built around systemd.

> As a sysadmin, systemd is very very useful in my job

I agree; as a sysadmin, whatever init system the OS offers is very very useful in my job.

What I have not found is that systemd is more useful than the other major alternatives. Can you outline, let's say, three ways where you find systemd solves pain points you had with upstart or sysvinit?

Easy - upstart is only half complete and filled with bugs that will never get resolved. Sysv init doesn't have a baked in way to automatically restart processes when there is a problem (or any advanced process management beyond starting and stopping services in a particular priority.)

The thing is... tmux etc etc are very much "hobbyist" tools in comparison to what Red Hat deal with. Red Hat doesn't want you to have to have a persistent shell session on a server - they have all manner of tools for central management of servers that you "should" be using instead, and needing to SSH into a server should be a very occasional thing.

Look at it this way - the primary use for tmux is having one's SSH client running all the time. Personal servers vs corporate ones. Barely anyone working on system software for Linux has anything to gain by supporting personal servers.

As best i can tell, the issue is not even with Gnome.

Its with a recent dbus update implementing yet another session concept (leaving it with no less than two, as best i can tell).

So you graphically log into a distro with a Gnome desktop.

This result in 6 different "sessions" being started.

In the kernel, that is largely transparent.

In X, again largely transparent.

In Gnome.

In dbus, twice!

In systemd.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact