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.
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.
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.
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.
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.
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.
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.
http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux
All they did recently was try to change the default configuration to enable the feature by default.
> 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
Systemd developer asks libc to add systemd specific code
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.
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)
I'm not looking forward to what comes next when Gnome breaks through the new system.
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.
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.
To them systemd is golden, as you can see with how CoreOS is basically built around systemd.
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?
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.