SoylentNews is people
SoylentNews
The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:
"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).
[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."
It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.
Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.
Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.
(Score: 2, Disagree) by SemperOSS on Monday May 30 2016, @10:48AM
Personally, I would not take it as an affront if somebody pointed out to me that by changing my code a little it would be able to support some systemd feature. I would mull it over, talk to my peers and make a decision whether to ignore it or not ... but causing an outbreak of systemd-bashing, I don't think so.
If systemd did not give you a choice, I could understand the sentiment, but it does. You can disable it at compile time (not an option for most, I know) or by making one little change of your setup.
So, why so serious?
Think about the early cars: No locks, you just opened the door and jumped in. Then suddenly somebody had the gall to put a lock on your car. I mean, what a pretentious idiot could come up with such an idea? Make a fuzz, shout from the top of the roofs, call on divine intervention ...
... Or just don't lock your door.
The choice is yours — and you actually have a choice!
All the same, I'm still going to hold on to Sys V init for as long as I can, systemd or not!
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 3, Interesting) by bitstream on Monday May 30 2016, @01:01PM
systemd just complicates matters. There are more productive things to do than to chase down how the system handles processes at logout. And on the macro scale it's about Red Hat trying to monetize free-open software. They need some serious negative feedback on this.
(Score: 3, Insightful) by Anonymous Coward on Monday May 30 2016, @02:08PM
I've been pretty ambivalent so far about SystemD, probably because I don't have the server management chops others have, but this decision here and in particular the reasons for it are very troubling. As another poster said, if the problem is that certain processes aren't cleaning up after themselves at logout, then fix that code. It comes off like SystemD is enabling bad coding.
(Score: 1) by kramulous on Monday May 30 2016, @11:56PM
I'm pretty much the same as you. I will add that when it came to having a program of mine run as a daemon, systemd was extremely useful and did the job well.
I don't think that it is enabling bad coding, more that it is cleaning up after bad code. God knows there is enough of that shit out in the wild.
(Score: 5, Interesting) by kurenai.tsubasa on Monday May 30 2016, @02:42PM
Personally I've been tepid about systemd. I've been meaning to throw it in a VM to play around with it since it looks like it's here to stay. I mean, if I ever got a Linux admin job, it probably wouldn't go over well if I said on day 1, “Tear it all down and install Gentoo!” For my personal stuff, Gentoo has worked well, and I'm glad they went with OpenRC. That way I don't need to learn the systemd equivalent of /etc/init.d/$service stop/start/restart/etc. :)
As far as dependencies, I have Weston (Wayland reference compositor) built and running just fine without systemd. Same goes for Enlightenment E20. I just added -systemd to my package.use and also a section in package.mask (labeled # Lennart Poettering) to be sure that masks systemd, PulseAudio, and NetworkManager.
(An aside: I've had problems with both PulseAudio and NetworkManager. Neither will just work, and when there are things like ALSA that just work or wpa-supplicant that just works after editing a simple config file, I simply have no need for PulseAudio or NetworkManager. User-friendly is in the eye of the beholder. When I'm the user, user-friendly includes editing a config file every now and then instead of bumbling around in a GUI trying to hunt down the option I want. Or in NetworkManager's case, taking whatever I do in the GUI as a mere suggestion and doing whatever it wants to do regardless.)
However, if systemd is breaking things like screen and tmux, that's a red flag for me. I'm used to being able to do stuff like starting a screen session in X, detaching it to log out, then logging back in on a console and re-attaching it. It's handy when I'm futzing around with Wayland.
So to run with your car analogy, it would be as though somebody wanted to put a lock on my car (that already has a lock) that sometimes wouldn't lock or unlock unless I shut my car completely off and started it back up. Then I'd discover that it just magically locks itself whenever it feels like instead of predictably doing so at 3 mph. When I report the problem, the person who wanted me to have this new kind of lock refuses to fix it and instead blames the rest of the door assembly! I'll keep my existing locks, thanks.
So basically, if screen in particular is broken by systemd, which TFA seems to indicate, systemd would break a use-case for me. It's also suspicious that the reason it's breaking tmux (and screen), at least according to TFS, is because Gnome can't clean up after itself. The whole thing just smells bad.
I mean, I brought up Wayland because I'm looking forward to it becoming mainstream or at least better supported. I wouldn't expect anybody to switch over to using it 100% right now. Nvidia claims support now but apparently they have a disagreement about some part of Wayland's API—fair enough since Wayland is the newcomer and it's good to see Nvidia's willingness to support it. Things are getting ironed out, but once support is there, I will be switching over from X11. I'm not afraid to do new things when they make sense, and everything I've read about Wayland makes a good deal of sense. Naturally it would, because it's the Xorg developers themselves who are now saying that the cruft runs so deep that even Xorg isn't cutting it. (Not to mention I remember how much of an improvement Xorg was over XFree86.) Hence, they came up with Wayland.
systemd on the other hand seems to be the brainchild of somebody who's already created two wonky, half-working packages, PulseAudio and NetworkManager, that at least seem to be trying to address a deficiency somewhere. With init systems, first there was upstart, which always seemed wonky to me, and now systemd. The whole thing seems like a solution in search of a problem, or at least a solution to problems that were caused by a single desktop environment I don't even use, Gnome. I'm also suspicious about just why we need an init system to handle Gnome's user sessions.
PulseAudio and NetworkManager at least are easy enough to tear out of Ubuntu-based distros. With systemd metastasizing across the entire base system (and let's be fair: systemd is modular if one takes a look), it's not looking very easy to pull that one out by the roots. When it causes problems with software like screen, given that so many distros have switched over to it, I think that's a practical enough concern to sound the alarm. Granted, this isn't as serious as when systemd was parsing the kernel command line and vomiting all over klog, but it's a clear pattern. Everything that systemd breaks is just somebody else's fault. I have a feeling that we don't hear so often about Wayland because there's no push yet to replace Xorg, and the developers aren't arrogant enough to demand that say Audacious change the way it works because gtk+'s Wayland support for whatever reason is putting the visualizer at the bottom in its own window instead of where it's supposed to be.
Even in that specific example with Audacious, I have a feeling that the visualizer is getting its own window under Wayland because the Audacious developers had to work around something wonky with X11. When it comes to screen and tmux, I don't see why something as simple as a trusty old daemonize needs to be broken. If I start a process, I intend for that process to keep running until it's done or I send it sighup. systemd is treading on thin ice by breaking that.
But essentially you're right. As a Gentoo user, I haven't had to give two shits about systemd. Yet.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:49PM
I hate to say this, but pulseaudio got better once the idiot poettering moved on from it. Network manager though is a piece of crap.
I use pulseaudio because i use steam on linux and many games need it for audio. apulse doesn't cut it and I have moved on from desiring to fiddle with a system wide asound or user asound file every time i want to do something different. Play games, put this in the asound file. Listen to music, have this instead.
Poettering may be an idiot, but linux DID need a better audio manager on top of alsa drivers. When he moved on to the 'next shiny thing' others made it at least palatable. I'll keep using pulseaudio until it becomes hard linked to systemD, then i'll jump ship to whatever fork is created by similar minded people.
Also just to point out a few years ago I would have sided with you, then I was forced with a choice. Keep having to do this, eat up more of my limited time after work and find myself limited even more in what games i can and can't play. Or just bite the bullet and use it. Turns out others made it better after he left and I was just being stubborn.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:10PM
There is apparently a way to make pulseaudio just a passthrough, without having it hog the alsa /dev files.
https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device [archlinux.org]
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @12:49AM
Ah yes, one of the many hacks i tried that didn't work.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @09:30PM
Oh, holy crap, YES! The hours I wasted on that POS when I didn't know better.
(Score: 1) by SemperOSS on Tuesday May 31 2016, @04:11PM
Your comment is well put and I agree with you on most of the points, but that said, it is actually somewhat off topic (as almost all other comments are whenever a specific systemd problem is mentioned). In this case, we should just be discussing whether other projects should cater for the new behaviour in systemd to kill all processes when a user logs out, or not, not systemd as a whole.
And yes, the two issues can and should be separated.
Whether systemd is fit for purpose or the wrong solution to a non-problem is not what this is about. Whether Poettering screwed up PulseAudio and NetworkManager or not is not what this is about (He did!) Whether systemd breaks applications like screen or tmux is not entirely what this is about either. (Although systemd does not necessarily break them as you can turn off the offending behaviour and have a system that works — in that respect, at least — just as it did before. A fact that seems to be completely overlooked in this discussion.)
What this is about is whether the systemd team should or should not make other projects aware that they would have to make changes to make their programs work correctly with this systemd feature enabled.
Another spin-off discussion could be whether the changed behaviour is actually an improvement or not. That discussion would be pertinent and something we probably could learn from.
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?
(Score: 2) by Bot on Tuesday May 31 2016, @04:31AM
You do not take into account that systemd is linux specific, and in a state of flux.
Why on earth should a free software dev complicate or fork his project to accommodate this? would you?
RH should fork it themselves instead of having unpaid volunteer time devoted to build castles on their sand.
Account abandoned.
(Score: 1) by SemperOSS on Tuesday May 31 2016, @03:52PM
In fact, I said that the developers should consider the possibility and either accepting it or rejecting it for inclusion in their project. The change may break some functionality but if you cannot live with that, disable the change, no reason to moan about it just because it is a pet hate project.
And just so you know, I have no connection to Poettering or systemd. In fact I try to avoid it as best I can, but please give the people some credit for not just forcing this change upon the unsuspecting world.
I don't need a signature to draw attention to myself.
Maybe I should add a sarcasm warning now and again?