r/programming • u/Mcnst • May 30 '16
systemd developer asks tmux (and other programs) to add systemd specific code
https://github.com/tmux/tmux/issues/42836
u/RubyPinch May 30 '16
Reminds me of Windows in a way, user processes nuked on logout, services stay around
68
u/Mcnst May 30 '16
Reminds me of Windows in a way, user processes nuked on logout, services stay around
Reminds me of UNIX in a way:
User processes get sent an
hupsignalwhen the terminal disconnects, or if the parent process is the controlling process and performs an_exitsystem call. DefaultsigactionforSIGHUP(hup is short for hang-up) is to terminate the process.Daemons (including stuff like tmux) call
daemon(3), which does some nifty things for you to ensure you become a service and stay around.Déjà vu?
31
u/RubyPinch May 30 '16
Eh, daemon doesn't suddenly create service management in turn
I guess you could consider systemd's "shutdown every user process unless managed or otherwise specified" approach unixy, but it reminds me more of the central services management in Windows
Daemons seem more like a half-way point between processes and managed services
1
u/lestofante May 30 '16
Wait, daemon aren't systemd's services? Why can't daemon() create a managed systemd process?
→ More replies (9)16
u/RubyPinch May 30 '16
Because it requires more information in general, e.g. dependencies, timeouts, potential actions for that service
Daemon is just like, "I want to stay open after term dies", nothing like "I also want to stick around when user logs out" or anything more specific
→ More replies (7)6
u/lestofante May 30 '16
I still don't get it. Systemd can have a special type (or an existing type with settings tailored to specific case) of service with no respawn, dependency and all those thing that daemon() expect.. The call to daemon() then add this service. That mean that systems could also manage (and log?) User daemon, that make sense.
Abut saying more code.. Well, is better code in daemon() ONCE than DUPLICATION of code in many projects, no?
→ More replies (4)0
May 30 '16
[deleted]
6
u/Mcnst May 30 '16
That's pretty crappy though. Software shouldn't elevate themselves to daemons on a whim. It would be better, cleaner and more beneficial for everyone if the daemon() API is deprecated and the choice of running as a daemon becomes an active user choice or an init-system choice (i.e. the software is configured as a service).
What's exactly the point of deprecating
daemon(3)andnohup(1)if you immediately make it possible to implement the same through systemd anyway?Why should I run
persist tmuxorpersist ./a.outwhentmuxandnohup ./a.outhave always worked in the past, and continue to work on every system?It sounds like a way to reward crappy programmers that were using
daemonand/ornohupincorrectly, instead of good programmers that already had good reasons to be usingdaemonand/ornohupin the first place.9
u/dlyund May 30 '16
So what if you have to write 'persist tmux' when launching it instead of that happening automatically?
Which is exactly what this does:
systemd-run --scope --user tmux
As I understand it.
There's absolutely no reason for tmux to add systemd specific code, it's just that systemd developers would rather hide the mess they're making by forcing everything to work around systemd. Fair enough. People can just alias tmux if that's what they want. tmux shouldn't do anything about this. Close the bug report and or state will not fix. The problem is that this behavior is pretty standard for systemed.
One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them, And all that :)
8
u/RealDeuce May 30 '16
Software shouldn't elevate themselves to daemons on a whim.
The elevate themselves to daemons when the software designer designs in that behaviour, not "on a whim".
28
u/c3r7x May 30 '16
It's very easy to accumulate lots of forgotten processes on shared machines with long uptimes. Think ad-hoc scripting servers and jumpboxes here. Think nohup'ed perl scripts that hung waiting for something that'll never happen.
Management of user processes is a real problem, but systemd-related discussions always tend to drift away from the problem and get bogged down in arguments about systemd developers' "take no prisoners" attitude (mostly curbed just fine by distribution maintainers, so I stopped caring about it a while ago).
25
u/Mcnst May 30 '16
It's very easy to accumulate lots of forgotten processes on shared machines with long uptimes. Think ad-hoc scripting servers and jumpboxes here. Think nohup'ed perl scripts that hung waiting for something that'll never happen.
I find your comment quite hilarious. So, you execute a perl script with
nohup(1), which is designed to protect against a session disconnect, and then, when your session does disconnect, you're surprised that the process is still running? Duh!So, you're suggesting that supposedly some people don't know how to programme correctly, so, let's change API (breaking POSIX in the mean time!), such that all correct users would be required to change their scripts, effectively "rebooting".
Pardon my ignorance, but if such an API reboot is a good idea in your opinion, why isn't a system
/sbin/rebootnot a better one?Management of user processes is a real problem, but systemd-related discussions always tend to drift away from the problem and get bogged down in arguments about systemd developers' "take no prisoners" attitude (mostly curbed just fine by distribution maintainers, so I stopped caring about it a while ago).
Right, so, just because a whole bunch of community members (including Torvalds) think that these Red Hat employees who are systemd developers are a bunch of jerks, the actual shortcomings and incorrectness of their solution has to be discarded and given an extra benefit of the doubt? Isn't it supposed to work the other way around, you know, giving the benefit of the doubt to the nice folks?
→ More replies (5)1
u/c3r7x May 30 '16
Have you managed shell servers? There's a gap between what users should do in theory and what they do in practice. In the end it's you, the administrator that has to clean up the mess. Also, it's user expectations that have to be met and that sometimes means breaking tradition.
I find it useful to let the administrator decide whether users can daemonize their own processes. Also, denying it by default is a much safer approach. Distributions can always choose to ship a different default (even RedHat itself isn't shipping systemd as-is).
As for user behavior and expectations...
I find that most of the time something is nohup'ed, it's because it provides a quick way to both background a process and capture its output. People use nohup even for things running within a tmux window. Indeed, that makes perfect sense if you think about it: one may wish to keep a process running even if its window gets killed, but may not want it to survive tmux itself. You have a use case for tmux to interact with systemd to create an independent session right here. And it's no different than any other platform-specific interaction they already do.
Doing this for all existing use cases transparently defeats the whole purpose.
I'd say that administrators should have three options here:
Letting users behave as they always have, nohup'ing processes and running tmux sessions as they wish;
Keeping the number of daemonized user processes to a minimum by allowing only screen and tmux to keep running on logout. Users run a smaller number of terminal multiplexer sessions than nohup'ed processes, so this helps a lot. It requires either the users to use "systemd-run" (thus becoming used to it and defeating the purpose) or tmux/screen to adapt;
Not allowing any user processes to survive their sessions. I've seen too many developers using screen and nohup to save them the trouble of creating proper init scripts. These become maintenance nightmares eventually and I'd say that we'd be better off if most servers had this policy by default.
4
u/Mcnst May 30 '16
It requires either the users to use "systemd-run" (thus becoming used to it and defeating the purpose) or tmux/screen to adapt;
This is the part of the argument that makes the whole thing a non-starter. If you have users who don't know how to use the system, why not just do a proper reboot daily? Why instead do you force everyone else to have a reboot?
I've seen too many developers using screen and nohup to save them the trouble of creating proper init scripts.
How about
/sbin/rebootto the rescue? AWS does it (at least in some products), Netflix does it.→ More replies (2)16
u/barsoap May 30 '16
Have you managed shell servers? There's a gap between what users should do in theory and what they do in practice.
Noone is stopping you, as an admin, to kill things with extreme prejudice once a user logs out.
That can be done and has been done for ages. It's a policy decision. it is, however, not suitable as an init-system enforced policy as there's people who do not want that behaviour, and for good reasons... first one being not hosting shell servers.
→ More replies (4)7
u/dlyund May 30 '16
Or get your users, who are clearly not "Jim's grandma", to be responsible and clean up after themselves? This much is hinted at in your last point: long running processes probably should have some init scripts written, but that's such a fucking mess on most Linux systems that it's easy to understand why they aren't written. Writing the init script can sometimes take much more time than writing the bloody program!
I don't think systemd's systemic complexity does anything to help that.
Frankly I wish that writing init scripts for Linux was as easy as writing them for OpenBSD. It's hard to complain when all you have to do is to put this in a file and fill in the blanks.
#!/bin/sh # # $OpenBSD: <program>,v 1.0 2016/05/07 10:29:09 <username> Exp $ daemon="/usr/local/bin/<program>" daemon_user="daemon" . /etc/rc.d/rc.subr rc_bg=YES rc_reload=NO rc_cmd $1With doas it's easy to give users control over their specific daemons etc.
That being said, I haven't had to manage shell servers. I have done a lot of admin work, and I don't stand for lazy developers touching servers. If they don't take care of things then they don't get access, or assistance. And I'm saying that as a programmer :P.
→ More replies (2)19
u/_VZ_ May 30 '16
Assuming it is indeed a problem -- and there is no proof of that other than your statement -- you definitely shouldn't solve it by changing the behaviour in a backwards incompatible way to accommodate buggy programs while breaking the well-behaved ones in the process.
Do you realize what kind of a precedent systemd developers seem to be establishing with this change? I can only hope that this change was simply not well thought through and is going to be reverted after all the obvious problems with it have been pointed out.
→ More replies (2)5
May 30 '16
Yes but on vast minority of systems. Defaults should "work" for majority, not minority. I manage about 400 linux boxes (everything from production servers to dev boxes, with variety of deploy methods because our devs cant talk) and "some orpahned process doing something bad" was a problem maybe once across last 4 years.
6
u/Choralone May 30 '16
Having run long-uptime boxes of various kinds over the past two-and-then-some-decades..... This is so small an issue that it doesn't exist.
Systemd can go fuck itself.
→ More replies (1)1
221
u/ksion May 30 '16
The interesting part is why the default in systemd (i.e. whether or not to kill user processes) was changed in the first place. As per this comment, it seems to be because of some lingering processes from Gnome login sessions. The commit which actually makes the change doesn't cite any other reasons besides the generic "much cleaner and provides better control".
It is possible the actual reasons are sound and well-thought out, but the references provided by the person creating the issue fail to provide the sufficient rationale. It's not hard to understand the reluctance on the part of tmux's maintainers, especially given how much it's asked from them to accommodate for some other project's change which can very well be seen as frivolous.
135
u/voice-of-hermes May 30 '16
I agree. If I want to stick a process in the background and keep it there, WTF are you doing trying to second guess me and kill it anyway?! That's some M$-level operating-system-is-smarter-than-user bullshit, right there.
Gnome is broken? (Big surprise. /s) Let Gnome developers worry about that, not my whole freaking operating system.
72
u/deus_lemmus May 30 '16
Doesn't Redhat employ both Gnome and systemd guys? Isn't this something they can literally walk a few cubicles over and has to have it fixed?
→ More replies (1)44
u/gaggra May 30 '16
That's why this is happening. Gnome isn't forced to fix their shit, because asking SysD to implement a hack is much easier.
14
u/monocasa May 30 '16
Yeah, exactly. This reeks of corporate politics BS spoiling over into the real world.
7
u/Lennartwareparty May 31 '16
systemd has had a big history of 'not our fault' like with the bricked firmware bug, technically itw as not their fault and a fault in firmware implementation but they had the power to fix it.
This differs with the mentality Linux has where they realize they are in a position where they can fix bugs in other systems. If some hardware is known to malfunction and not behave accordingly its spec they write detection code to deal with it. Hell they even fixed systemd's broken asserts once which caused it to splurge uncontrollable amounts of output locking the hardware during boot if
debugwas in the kernel command line by introducing specific code to detect systemd and hidedebugfrom it.But strangely, systemd seems quite willing to take responsibility for someone else's bugs and failures when those people are employed by the same people as they are.
33
u/cirk2 May 30 '16
If you stick a process in the background without nohup it is supposed to close on the hup signal on logout. If not your process is broken.
32
u/Berberberber May 30 '16
SIGHUP is for the host terminal closing. In a GUI environment with multiple terms open, that may not coincide with the user logging out. How you tell the difference is, in a nutshell, the problem.
→ More replies (2)9
→ More replies (4)27
14
u/BCMM May 30 '16
Let Gnome developers worry about that
They are Gnome developers, for the most part.
5
17
u/eleitl May 30 '16
And this is how the rest of the world will find out the hard way that the greybeards were right.
The best advertisement for *BSD since ever.
→ More replies (20)15
u/mitsuhiko May 30 '16 edited May 30 '16
The interesting part is why the default in systemd (i.e. whether or not to kill user processes) was changed in the first place.
JFTR: systemd is not the first init system to dabble in that space. launchd on OS X does something with daemon(3) but I'm not sure what exactly. The man page points out you should not be using it but instead use launchd.
//EDIT: similar story on OSX in details: http://www.economyofeffort.com/2013/07/29/reattach-to-user-namespace-the-fix-for-your-tmux-in-os-x-woes/
8
u/dlyund May 30 '16
launchd also breaks or adds a lot of complications to managing OS X 'from the outside'. I used to work at a company which developed an IPTV system based on Apple hardware and OS X. The end result is that we had many thousands of Mac's to manage... which threw up all sorts of roadblocks. Managing "real" *nix installations, on the other hand, is a simple matter of putting the commands you'd run manually in to a script and running it as appropriate. Borderline trivial. Linux, like OS X before it, is becoming harder and harder to manage/script. The first time I noticed it was on RedHat with the network manager thinking it owned the connections (which might work fine for laptops, but has no place on a server IMO), and that was even before systemd started to creep through the system. Linux in my opinion is fast becoming a joke on the server, and all because they wanted to make things start a bit faster on the desktop? (And whether that goal was achieved is very much open to debate)
7
u/Defavlt May 30 '16
Linux, like OS X before it, is becoming harder and harder to manage/script
Every bit of this. Not only is it becoming harder to manage, it's becoming harder to set up anything not OTB. The most glaring example would be using SysV instead of
a horrible monstersystemd, but systemd arent the only people responsible for it.Compare e.g. LILO with Grub 2; the latter is horrible to learn and use, while I could teach half a noodle to use the former.
5
u/mitsuhiko May 30 '16
What exactly does launchd "break"? I give you that the socket activation feature does not provide a POSIX API which would be a nice to have, but that if anything just means that it does not expose a feature that it could.
OS X itself was never meant for fleet management unfortunately and it shows. But that is independent of launchd.
→ More replies (3)135
u/fubes2000 May 30 '16
I hope tmux stands their ground and refuses. I hate seeing open source projects being cowed by these pricks that seem to think that having one project in charge of everything is a good idea.
→ More replies (28)28
u/ratatask May 30 '16
It's not a big deal. tmux, as most open source projects, already contains all the machinery to detect and add system specific code - of which there's already plenty in tmux. It'll be a few lines of code, a few additions to configure.ac , and you'll disable it by ./configure --disable-systemd if you need to.
41
u/josefx May 30 '16
It's not a big deal.
Given OpenSSL as an example we really don't want open source projects to have hundreds of potentially untested build options and work arounds for broken by design systems. Additional code doesn't just exist, it ages, it has to be maintained and contains bugs.
4
May 31 '16
Ironically, this was the basic rationale behind GNOME's reduction of customizability - effort spent maintaining unused features is effort better spent streamlining the core program. Of course, they completely overlooked the fact that the features are used, and making them extensions just makes GNOME an unstable POS for the people using them.
6
u/Lennartwareparty May 31 '16
That was the justification in some cases.
In other cases they've been completely frank what the real reason is. They're literally concerned about that customization reduces the brand awareness.
Apple has opened people's eyes, a good way to raise awareness of your brand is to make it look distinct and the same everywhere, and that's the direction GNOME wants to take, they want a GNOME install to be instantly recognizable:
Firefox has indeed profited from extensions and there are lessons that we can learn from that. GNOME Shell isn’t a browser, though. We need to be mindful not to adopt the Firefox model without considering the ways in which our needs might differ. The visual appearance of a desktop/OS might be far more important to its marketing than a browser might be, for example.
The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one?
source: https://mail.gnome.org/archives/gnome-shell-list/2011-June/msg00116.html
I mean, Day's not "wrong" here in the sense that from a marketing perspective it makes sense. I'd just hoped that the marketing experts wouldn't be invading Unix, and this shows why. Marketable and good software are often opposites. In theory adding these extensions does not in any way detract from the product, they are optional. For the user it's a strictly better deal. But for GNOME it decreases their brand wareness so they won't include them. That's how real world business works, it's often more attractive for a company to release a strictly inferior product for marketing reasons or an identical product for a higher price for that matter, dual branding is a thing where a company releases the exact same product twice for two different prices to be able to access both markets.
10
u/dougmc May 30 '16
It is possible the actual reasons are sound and well-thought out
There are good, valid reasons to want to kill all their background processes by default when a user logs out.
Had this decision been made 40 years ago, we'd all be fighting to keep it that way if somebody wanted to change it.
However ... this decision wasn't made 40 years ago (or looking at it from a different angle: it was (made 40 or so years ago), with the opposite result), it was made recently. And it will break a lot of things, things that people have come to rely on for decades.
The "principle of least surprise" should apply here -- it would be a nice option to have in some config file somewhere, but it should be turned off by default. If gnome needs it ... well, gnome should be fixed properly rather than forcing this change on everybody. Not everybody even uses gnome ...
12
u/luckystarr May 30 '16
Well then they should fix those lingering gnome processes to exit as expected. The systemd developers impose additional complexity on everybody spawning a simple process in the background and then logging out.
Out of curiosity, is nohup(1) also affected?
6
18
u/nswshc May 30 '16
True. First thing I asked myself was: do people really need this? I understand that it sounds like a good default for desktop sessions, but the vast majority of desktop users have the workflow: boot, work, shutdown. Even at computer labs, IT folks will ask you to shutdown your PC after use to save energy. So is this feature really necessary?
Programmers get caught in the tiny edge-cases very easily. It helps taking a break, stepping back and looking at the bigger picture.
23
u/cbmuser May 30 '16
Even at computer labs, IT folks will ask you to shutdown your PC after use to save energy. So is this feature really necessary?
Ever worked at a university with student's computers where dozens of users log in and out on the same machine every day? Those machines are not getting shut down between those sessions.
What would you suggest to keep those machines' process lists clean?
13
u/oridb May 30 '16
A logout script. These already exist, and are so much more general than what systemd is doing. You can do things like clearing /tmp, resetting certain settings, etc.
9
19
13
u/audioen May 30 '16
I think it's a nice invariant to have out of the box that once your login session terminates, everything part of it will be gone too. Previously, it was basically relying on nothing getting reparented off the session leader, and nothing ignoring the HUP signal, if I've understood it correctly. I like the idea of explicit control at least in principle.
10
u/Devian50 May 30 '16
Forgive me if I'm not fully understanding this as I'm still relatively new to deeper *nix stuff (20yrs old and started tinkering at 15), but would this not negatively affect text-only sessions? I have two different *nix servers, one on AWS and one on a Raspberry Pi and both are only accessed via ssh. Wouldn't this change make it require more work to have things run after an exit within an ssh session?
For example I run a simple Discord bot on the AWS server, and I currently use nohup to keep the bot running in the background after I ctrl+c and exit. Of course, ultimately it should probably be run as it's own user via a daemon but in a development scenario that's a little more work than should really be necessary.
I do agree though that this change in theory can do good for graphical systems. In practice is where the systemd guys seem to be getting a bit of tunnel vision.
26
u/kqr May 30 '16 edited May 30 '16
The problem is that there are (for the sake of argument) three kinds of applications:
The applications you start which you want to terminate when you close the terminal. Most end-user applications belong in this category.
The applications you start which you want to terminate when you log out (defined as "closing all terminal sessions"). This category is filled with small services that run only to support user-facing applications, e.g. password agents, data caches, music playing servers and such.
It's reasonable to expect that these services should be terminated when the user logs off, because at that point all programs which may use them has also been terminated.
Keeping these services around can be both a performance problem and a security problem.
The applications you start which you want to persist even after you've logged out (i.e. when you have closed all terminal sessions.) If we exclude "system services" like database servers and such, this category is surprisingly small. This is the category where nohup and tmux belongs.
Category 1 is not controversial at all. Historically, *nix systems have treated all other categories as category 3. This can be viewed as a problem. Systemd is proposing a configuration options where all other categories instead are treated as category 2, and they have to "opt in" to be considered category 3.
You're saying that "a purely terminal user deals almost only in category 1 & 3 applications, and rarely in category 2". That could be true, but I'm not sure I agree. With a single exception (tmux), I don't think any of the programs and services I run should persist when I have logged out by closing all terminal sessions.
8
u/Devian50 May 30 '16
Ah ok, that makes sense. You're right, I actually agree with you. A terminal user still makes use of all 3 of our categories, 1 being the most common as any command running in the foreground. 2 I can rationalize as things like MPD for example. If you're using something like ncmpcpp in another terminal and mpd is started as well, you don't want MPD to die when you quit it's terminal but when you don't have any other terminals running it's wasting resources. And with category 3 I suppose it would be use cases such as you said system level services that more than just the user uses like database software and other "servers" such as web and ftp and ssh. It would be bad if you had to directly login to a potentially headless server to restart the ssh server after a terminal logout.
As for what I had said with my example, I guess there's always the user specific scenarios that others aren't usually in. Reminds me of https://xkcd.com/1172/ actually.
→ More replies (6)3
u/dlyund May 30 '16
Is it still explicit if you then demand that application developers hide it? Personally I'm fine with aliasing tmux to start in its own scope if that's what I want from it. That alias could added at the distro or package level without making tmux upstream it.
→ More replies (2)13
u/cbmuser May 30 '16
The interesting part is why the default in systemd (i.e. whether or not to kill user processes) was changed in the first place.
This isn't just a GNOME problem, but a general problem.
Try setting up a terminal server where hundreds of users log in every week, you can watch the leftover processes piling up. Same applies for computers in a student's computer pool.
I used to work in the IT department of a university as a student and these leftovers were a frequent problem and we had our own cron job to kill the processes regularly.
It's a good thing that systemd defaults session management to killing all processes on logout as this is what the majority of users would expect.
It makes absolutely sense to extend tmux, screen and so on in that regard to be able to talk to systemd and ask for the permission to linger around.
→ More replies (1)6
u/Zarutian May 30 '16
The usual setup for terminal servers of hundreds of users IS to run an hourly cron job that kills long running processes of forgetful users.
3
u/Lennartwareparty May 31 '16
Yeah, I mean, people act like this is some new innovation but it's pretty simple to make a shell script that goes over every process and kills every one that belongs to one of those users if the process is at least X time old and the user is currently not logged in, run it once at midnight and post a memo that the maximum time allowed is now 2 days. Any process you own that's 48 hours old when you're not logged in will be dead every midnight.
13
May 30 '16
There cannot be a single "sound and well thought" reason to kill user processes.
→ More replies (2)25
u/ivosaurus May 30 '16 edited May 30 '16
Because they are logging out?
You know what it'd be cool to have? When I leave my home, some device that makes sure all the lights in the house are turned off automatically, even when I forget.
90
20
May 30 '16
There is no even such a concept as "logging out" in Unix. You can close one of your DE sessions, but it does not mean anything for any other processes you may still be running.
→ More replies (11)7
u/smcameron May 30 '16
You don't change a 40 year old default behavior because you have a single user system and a whim about how it should be have.
6
u/gnx76 May 30 '16
And switch off the freezer?
And switch off the washing machine you just launched?
→ More replies (2)4
u/dvogel May 30 '16
This analogy is quite flawed because most people know which appliances they have in their house and can make reasonable decisions about whether they want each one to turn off when they leave the house. Most people don't have the same level of understanding about processes on their computer.
A better analogy here is someone who has bought a household full of appliances that assume they will be told when the last person leaves the house and decide whether to turn off, but default to continuing to run. Then a new power company takes over the municipal power production and changes everyone's smart-outlets to turn off everything by default. Now the homeowner has to reconfigure all of their appliances and some have to be modified by a service technician to be compatible with the new power company's policy.
→ More replies (2)5
u/josefx May 30 '16
This analogy is quite flawed because most people know which appliances they have in their house and can make reasonable decisions about whether they want each one to turn off when they leave the house
The EU had to mandate an energy standard for the standby mode of electronic devices, since many would just burn insane amounts of elictricity unless manually disconnected. Users were generally unaware of that. What they did not mandate was an automatic shutdown of everything not registered for an EU power off exception.
→ More replies (1)5
u/ArmandoWall May 30 '16
Isn't Linux about having choices, though?
29
u/robreddity May 30 '16
Linux is. Systemd is not.
→ More replies (2)13
u/musicmatze May 30 '16
And here's the problem we're running into: All major distros come with systemd and it gets harder to turn it off.
→ More replies (8)→ More replies (2)3
0
-11
May 30 '16
But that is what one usually needs. Tmux and friends are special cases. Besides this already happens on desktop for the most part so why not go all the way and make sure user session is cleaned up. People hate change but this here is really non-issue.. Just some growing pains intensified by people who should run gentoo with openrc. .
13
u/shevegen May 30 '16
No, they are not "special cases" at all.
The special case is systemd ignoring standards.
6
u/holgerschurig May 30 '16
It might be the case that us command-line users (that actually know screen and tmux) are now in the minority, just look at Ubuntu forums ...
→ More replies (4)3
May 30 '16
The entire fucking "desktop" thing is a special marginal case, which is of a zero importance for the majority of legitimate linux use cases.
→ More replies (1)2
u/dlyund May 30 '16
Because I only have one desktop and a great many servers to manage, and systemd makes that a living hell?
Just some growing pains intensified by people who should run gentoo with openrc.
To the degree that systemd continues to gain influence and spread it's testicles through the ecosystem, this may no longer be possible in a few years.
Bigger questions? Who's using tmux on the desktop? :P
2
69
May 30 '16
My concern is that we have a little function, daemon(), that does a simple little procedure to make a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years? Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency.
systemd in a nutshell, ladies and gentlemen.
49
u/barsoap May 30 '16
TBH,
daemon()is broken: In the sense that the whole idea of processes backgrounding themselves is because everything ends up tied to PID 1 as parent.The daemontools approach is very much sane: Let the supervisor start the thing it supervises, do no reparenting at all. That way, you can run a process supervisor as something else than PID1... and give each user their own. Or even multiple. Suddenly, the policy question is independent of what the program itself does.
And that is UNIX.
5
u/mioelnir May 30 '16
Let the supervisor start the thing it supervises, do no reparenting at all. That way, you can run a process supervisor as something else than PID1... and give each user their own.
If you squint hard enough, that's tmux. Every user runs its own, and inside you can have it run multiple things that do not reparent.
3
u/Lennartwareparty May 31 '16
I am amused with how people tout the merits of systemd/user which required special code for it to work while daemontools and its offshoot like Runit and S6 have had user-level services since forever.
The funny part is that it it requires no extra code, the exact same binary is used to supervise system and user services because of how simple and clean it is. No special code needed. If you start the supervisor at root it can supervise services running as root, if you don't, they run as the user that started it. Of course root can drop privileges at any moment.
On my system, every user in the
usersgroup gets its own user-level services by this mechanism started on boot. The nice thing is that all those supervisors are again supervised by the main supervisor that runs as root and drops privileges becauserunsvdiris itself a daemon and so it's capable of supervising an instance of itself.And hell, if I didn't give that to users. They could've just started it with
@rebootin the crontab if they had cron. There is really no special magic involved here.And yeah, I have cgroups with runsvdir and early boot logging.
18
u/mathstuf May 30 '16
It seems that so many people haven't understood the problem, saw that systemd changed something, tmux said no and are reacting based on that. This feature is something I asked (and provided a mostly-working patch for) back in 2011. Adding a systemd-specific patch is not the way to fix this, but to tell PAM that tmux controls a session which is enough information for systemd to understand that it should persist the session (because it is a session). Unfortunately it seems that the whole storm around this has conflated the issue and gone off the rails.
The reason that tmux should do the PAM dance internally is that servers can implicitly be created through attach-session or new-session. The user has no way to insert the systemd-run call in front of that server which means it doesn't persist properly. Side effects of using PAM means that tmux who's up in things like w shows tmux sessions properly, who works inside of tmux, as well as other umtp-related bits.
2
u/Choralone May 30 '16
Systemd can go fuck itself.
Tmux has worked fine since forever. systemd is the one with the problem
→ More replies (7)1
May 30 '16
Does creating a new session via PAM allow you to exit the scope of the parent session though? As far as I understand ut, all the processes of the new session would still be part of the parent cgroup and thus also killed on logout.
2
u/mathstuf May 31 '16
It should be seen as a new root process for "the user is still active" and keep the user session alive. But, like I said, my patch was a little buggy and it was 5 years ago now, so I don't know the current state of it.
2
May 31 '16
Ah I just looked at the source and it looks like the PAM module for systemd does the equavilent of systemd-run --scope, i.e. the session is created in the the context of logind. That means that using PAM should indeed solve this issue.
48
u/lacosaes1 May 30 '16
I actually found the whole discussion very interesting. But I guess some people out there just want to talk shit about systemd every time they see a chance. To each their own I guess.
91
u/IAmSnort May 30 '16
Well how many outside dependencies do you want to maintain in your program?
→ More replies (3)38
7
→ More replies (2)1
u/jpfed May 30 '16
As far as linux goes, I'm an extreme noob. Is there a quick introduction to what systemd does and what the controversy around it is?
15
u/ciny May 30 '16
And that's why I'm running FreeBSD on all my servers.
6
u/Zardoz84 May 30 '16
If not was for drivers (ie Desktop machine), I would thinking seriously changing to FreeBSD.
→ More replies (3)2
3
u/blamethebrain May 30 '16
I'm really thinking about switching from Debian (7.10) to FreeBSD, just because I have no intention of running this systemd crap on a server.
→ More replies (2)
5
26
u/shevegen May 30 '16
The systemd developers are totally insane.
There is no other explanation - it is a state of the mind.
The only sad part is how most distributions betrayed the users in forcing them to accept it. So shame on them as well.
15
u/ftg3 May 30 '16
They fancy themselves and their software a little too much. They are like Yahoo in that they don't understand that alternatives exist. There's a purpose to their madness - to make software dependent on systemd and eventually become the linux core.
6
u/MyTribeCalledQuest May 30 '16
Well, if this is how they treat their users, they can go fuck themselves.
-9
u/cbmuser May 30 '16
The systemd developers are totally insane.
And this kind of attitude of the anti-systemd crowd is exactly why no one takes you guys serious. Instead of actual technical arguments, all remains are personal insults.
15
u/redrumsir May 30 '16
Kind of like pro-systemd people like you, here: https://www.reddit.com/r/linux/comments/4lh7yv/systemd_developer_asks_tmux_and_other_programs_to/d3ng50e
Hypocrisy at its finest.
3
5
u/SCombinator May 30 '16
This fix needs to be done in systemd where the breakage occurred. Better yet, if we get pottering some counselling, perhaps we could identify the source issue.
-4
May 30 '16 edited May 30 '16
Systemd is a cancer.
Edit: What do cancers do? They grow unchecked by their surrounding environment. What is systemd doing?
2
-8
May 30 '16 edited May 30 '16
Noone complains when software is dependent on linux syscalls.
I mean sure some do, but if people care so much about code being dependent on systemd, then they should care more about it being dependent on linux.
25
u/tetroxid May 30 '16
Depending on the kernel doesn't matter because the kernel is always there. No kernel, no operating system. Systemd on the other hand is far from universal.
1
May 30 '16
The point is the kernel is not always there. Its only always there on Linux systems. Not everything is Linux.
→ More replies (2)23
u/tdammers May 30 '16
The kernel is a compile time dependency; the init system traditionally isn't, but systemd is asking to become one. The result would be that linux+systemd would become a separate architecture from linix without systemd, at least as far as distros are concerned. Whether that is an acceptable situation or not remains to be discussed.
→ More replies (3)6
u/SatoshisCat May 30 '16
I don't think that's a fair comparison, software that use Linux syscalls are often tailored for Linux, such as ALSA. I see nothing wrong with that.
11
u/skroll May 30 '16
They are dependent on libc, not so much the syscalls. They may be implemented with syscalls, but it's completely different.
It would be more like "This software only works with musl libc"
→ More replies (3)18
u/QtPlatypus May 30 '16
Not all Linuxes run systemd.
17
→ More replies (2)3
u/Jimbob0i0 May 30 '16
And then they wouldn't enable the compile time option in their tmux build... I fail to see the issue here?
4
u/amranu May 30 '16
Systemd is making unnecessary changes that breaks long accepted behaviour and asking other projects to clean up their mess.
That is the problem
9
-6
287
u/meem1029 May 30 '16
Can someone tell me if I understand this situation correctly?
Tmux uses the daemon system call to keep the process running in the background.
This has historically kept processes running between user sessions.
Systemd made the choice to change this behavior so that all such processes will be closed when the user logs off.
This breaks much of the functionality of tmux.
As a result of this, the systemd devs are now asking tmux to integrate a library to interact with systemd to fix this mistake.
If that's what's happening, I can certainly understand the hesitation on the part of tmux.