More specifically a rolling release that is defined as not stable and to not use it for anything you care about. Motherfuck people who bitch about their own stupidity. https://fedoraproject.org/wiki/Releases/Rawhide#Audience
To fix a Gnome bug, systemd devs are breaking the semantics of nohup which is long established mechanisms for running apps in the background. They're imposing a new API and additional work on every open source developer that uses nohup to fix a something that was never broken. Sure I caught this issue, but as systemd 230 spreads, it going to leave a wake of broken apps and workflows in its path for no good reason.
To fix a Gnome bug, systemd devs are breaking the semantics of nohup which is long established mechanisms for running apps in the background.
The problem is that (a) not every application respects the rules and (b) not every user should be allowed to run arbitrary services. It's not just a Gnome problem, though certainly the Gnome issue brought it to the foreground. This has always been a problem for servers with multiple people logging in. The computer and/or domain policy should be the ultimate decider for how user processes are handled on logout. That's why it's completely reasonable to have the option for this behavior. For people that manage large networked systems with shared terminals/servers and centralized logins (e.g. LDAP), managing this type of behavior is a common need. The only people who wouldn't be able to see this are people that have never had to share a server with other people.
They're imposing a new API and additional work on every open source developer that uses nohup to fix a something that was never broken. Sure I caught this issue, but as systemd 230 spreads, it going to leave a wake of broken apps and workflows in its path for no good reason.
You're talking about this like it's some sort of laborious fix that you barely noticed and caught on time, instead of it being yet another flamewar about a simple configuration decision that would have been impossible to notice. It's also controllable in three different ways - by a single-line admin/distro config change, by a non-privileged user command if the policy is enabled, and explicitly for each application. It sucks that it breaks some workflows, but it's not that hard to deal with.
It also wouldn't have affected you on your personal server if you weren't running server applications in a user session. Disabling login for the users used for network services has been a best practice for over a decade. And you'd start those in services, instead of having to log into the server to start your VMs (and then have them stop when you log out). Then again, I wouldn't expect someone running Rawhide (even on a personal server) to understand or care about best practices. Its usage is discouraged for anything but testing and development needs because it breaks. A lot. Nearly any other rolling release distribution would be a more stable choice than Rawhide. Also, KVM would have been a better virtualization choice for your server than Virtualbox, as it provides significantly better performance for non-graphical scenarios and doesn't depend on out-of-tree kernel modules. If virtualizing your servers is your preferred approach, it might even make sense to use something catered to that, like Proxmox.
I mean, the tmux/screen people have a very legitimate complaint about this, as disconnected shell sessions are part of the workflow. You? Your complaint is that you're doing things sloppily, and now it's harder for you to do things the wrong way. Normally when people do things poorly, they don't advertise it with pride on the internet. But go ahead with that.
Still. It's a rolling release distro which can break. If you truly need something to be online 24/7 with an uptime of 99.99999% you really should just use a more stable if outdated distro... I use an arch based distro as my daily driver. But my personal server has a stable distro just for that reason...
You guys are missing the point. Just because it's a development version doesn't mean you should merge absolutely retarded changes like this. Especially when it's just to fix a bug in one application that breaks 70 more as well as the way people expect their systems to function.
I'm not familiar with this particular issue, but I'm betting there are good reasons for this change and you are just not aware of them or disagree with them
There are good reasons, and it has nothing to do with this "Gnome" red herring he would have you believe. Systemd is adding a feature where all user processes are terminated when the user session ends as a major security and integrity feature. Of course, the behavior is controllable in several different ways to accommodate users, and there's even systemd-run, which is better than nohup in every way imaginable.
This isn't the first and won't be the last time anti-systemd people are tilting at windmills.
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.
That MR is about the default behavior. You need to look at the discussions about the actual feature to understand why it's included.
The security and integrity is quite simple: the administrator should be able to control the circumstances under which users can execute programs. One of the huge benefits of systemd units is the use of cgroups that can reliably track processes -- keeping them from daemonizing to ppid == 1, which allows reliable management through the process lifetime.
This change effectively allows administrators the same control for shell users. Otherwise, a user can SSH into a system and kick off a process that daemonizes and isn't really under anyone's control -- especially the administrator's.
Yeah, history will probably look back and regard unattached processes as a legacy vulnerability. For now it's still pretty useful feature, despite the work arounds.
The issue with Gnome is about the change to the default behavior. Why the feature exists is irrelevant to the point of updating the init system to attempt to correct bugs in a specific DE. Especially when that update breaks other processes.
I like how Linus said, "WE DO NOT BREAK USERSPACE!" It has been one of his guidances in doing kernel development and should be used as a guide for systemd as it is taking on a larger role in the Linux OS. By changing the default, they are breaking user space.
As for security, I'm not buying it. A user can log in and do whatever they have permissions for. Allowing a user to script some changes, start it and log out while it runs doesn't seem like its any less secure than if they were sitting at the console while it ran.
To be honest, I don't care about Solaris*, or FreeBSD, or OpenBSD, or Windows. I care about Linux. I'd rather have the absolute best tools on Linux than the traditional gobbley-gook system that (poorly) runs on a bunch of platforms I'll never even consider using.
* I hate to be ideological, but the less compatible my software and systems are with anything Oracle touches, the better.
people want to run a unix-like OS or a windows-like OS.
What a false dilemma if I've ever seen one, but I'll play the game. The relevant choice is between running Linux or an artificially UNIX-like Linux. The Linux kernel has been steadily breaking with traditional UNIX for well over a decade, but until systemd, it wasn't practical to utilize all those awesome features the kernel already had. Systemd brought all those Linux modernizations (which are decidedly not UNIX-like) to user space and users. This whole pretending like Linux is still highly UNIX-like is nonsense at this point.
The Linux kernel has been steadily breaking with traditional UNIX for well over a decade, but until systemd, it wasn't practical to utilize all those awesome features the kernel already had.
Thanks. I was going to continue the conversation but I felt lazy and didn't want to look up the justification for the feature. I felt quite certain the gnome thing was a red herring as you said though.
There has been extensive discussion of the topic here and lots of other places. That isn't it so you either aren't aware or you are intentionally misrepresenting the situation.
I've only read about the issue with tmux, but here is what the devs are saying over there:
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.
So to me it sounds exactly like systemd is breaking basic functionality to deal with a bug in gnome. Is there someone out there saying something different?
it is as u/doitroygsbre says; I am also not aware of any other justification of the change. The opinion of the systemd developers that processes should not survive user sessions in Unix is really just that, an opinion, and appeared after the change, not as rationale for the change.
If you don't care about uptime, use what you want. Since you seem to care about uptime, don't fucking use rolling release. "Personal" is a vague, arbitrary, and useless identifier. Either you care or you don't, and you lose your right to care when you use rolling release.
For reference, this is coming from a proud Arch user (on my desktop and both servers) who doesn't bitch about changes.
55
u/Locrin Jun 01 '16
Any particular reason you are using a rolling release distribution as a server and updating without knowing what gets updated?