Hacker News new | comments | show | ask | jobs | submit login
Systemd developer asks tmux to add systemd specific code (github.com)
194 points by awalGarg on May 29, 2016 | hide | past | web | favorite | 282 comments



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.

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.


... 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.


Why is this upsetting to so many people? This seems to me like a simple request to add platform-specific code, and in the end there was a decision to take a different approach to solve the problem.

Seems to me like yet another systemd two minute hate. It's getting quite tiresome to see.


Red Hat developers decided to break the semantics of nohup/daemon(3), which are long established mechanisms for achieving the ability to run beyond user logout.

They then decided that, rather than encapsulate fixes for their breaking change in portable APIs like daemon(3) and PAM to allow user space to keep working as intended, it'd be easier to just outsource the labour onto the community by demanding every user space program that was working just fine do the work of adding a couple of hundred lines of systemd specific code directly, encapsulation be damned.

That's an insult to the tmux developers in particular, and disdainful of Open Source devs in general. Don't show up at my door telling me to do a bunch of work for you to fix your shit. You broke the contract; encapsulate the fix so I don't have to care.


Nohup was invented in response to a new SIGHUP which broke persistent processes. And today, it is accepted as the Right Way. This is no more an insult than removing cgroup write access from processes or any other new kernel feature.

Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance. Think about Chrome having flags to "run background processes after app is closed".

Systemd is trying to maintain backwards compatible behavior by collaborating with developers. We should not do these things cost "that's the way they've always been" is killing innovation.


> Nohup was invented in response to a new SIGHUP which broke persistent processes. And today, it is accepted as the Right Way.

Correct

> This is no more an insult than removing cgroup write access from processes or any other new kernel feature.

False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money.

> Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance.

There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result

> Think about Chrome having flags to "run background processes after app is closed".

What would stop Chrome from doing that under this new regime? Literally the only difference is that they'd be accomplishing that via systemd-specific code rather than portable, SUS-compliant code.

Ultimately all this change is accomplishing is deprecating simple, portable interfaces for achieving nohup behaviour with baroque, dbus-laden, systemd-specific ones. Red Hat's goal here seems to be little more than increasing systemd's surface area; otherwise, why not simply hide the sausage-making systemd cruft behind the portable API?

> Systemd is trying to maintain backwards compatible behavior by collaborating with developers.

"Collaboration" is not a synonym for "I have altered the user space contract. Pray I do not alter it further".

> We should not do these things cost "that's the way they've always been" is killing innovation.

"Innovation" is not a synonym for "instead of a daemon(3) call, here's 150 lines of dbus crud to get right back to where you were before".


> There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result

The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped. The new cgroup-based system makes it impossible to evade being reaped by playing games with fork. This mechanism is valuable, but it is possibly not the best default for most systems.


The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped.

And this is a red herring. If the process is malicious, it can just as well use this systemd method to keep from being killed and continue to do its dastardly deeds in the background. Logically, this "feature" can not be about controlling purposely malicious programs, because there's no way to determine if a process is malicious or not just by asking it or by having it assert that it is not. The only reason this exists is to paper over bugs in either the way these daemons are spawned (ssh-agent and pgp-agent, for example, work best when they appear in the execution inheritance hierarchy, rather than as separately spawned programs that run as siblings) or in the way they detect that a session has ended.


But isn't this mechanism they're asking tmux to use a way to evade being reaped?


Essentially.

You can't guarantee reaping while allowing for opt-out semantics for things like tmux. Everyone who thinks that's some innovation being achieved here is misunderstanding it.

This is originally about some GNOME daemons sticking around when they shouldn't. GNOME should just fix that, of course, but it points to the hole of it being all-or-nothing when it comes to nohup'ing. There's no good mechanism for asking for more limited lifetimes.

Of course, the Right way to solve that would be to leave the existing API alone for the all/infinite lifetime case, float a proposal for a new API for the limited case, raise consensus, implement it, and encourage devs like GNOME to move to the new limited case.

But that might mean actually talking to the community and building an encapsulated API that could be reimplemented on other platforms. So much easier to break everything and demand the world keep up, with the added benefit of all those raw dbus calls and hard-coded end points making portability off of your 2 billion dollar cash-cow OS just a bit incrementally harder, again.


False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money.

Isn't the usual answer to this, "If you don't like it, fork it?"

If you work on a large FOSS project, you will spend a lot of your time reacting to decisions made by other people. You won't agree with all of them. Some of those decisions will be made by $2B companies, some of them will be made by influential individuals like Linus and Lennart. Still others were made 20 years ago by some anonymous person in their basement.

Either way, if your complaints fall on deaf ears, your options are limited to living with it or forking it. That's just how it works.


> Isn't the usual answer to this, "If you don't like it, fork it?"

Zbigniew Jędrzejewski-Szmek, systemd developer, is asking for tmux to change to incorporate some systemd-specific Desktop Bus code. Nicholas Marriott, tmux developer, replies that this should go in the GNU libc daemon() function for everyone whose programs do this to benefit, repeating what he said 5 years ago.

Following your model, which should Zbigniew Jędrzejewski-Szmek be forking? tmux? Or GNU libc?


I was just thinking this. It seems to be tempting fate and encouraging a "$2B company" to make changes that suit their objectives.

It does seem like what is being requested is not a sensible change, but arguing with insults and getting so personal seems like poking a rather large bear with a very short stick because it is trying to make you move away from it even though you were there first. You can do that, but it's unlikely you will enjoy the outcome.


> Systemd is trying to maintain backwards compatible behavior by collaborating with developers.

I think you should check what "backwards compatibility" means, because it's the total opposite of what you're describing


Then these developers should be patching the broken processes, not breaking things for people who are using them correctly. This is the fundamental flaw of systemd -- it ignores every other project because the systemd developers are obviously right and everyone else is ignorant.


I can imagine friendlier ways of "collaberating" than "oh, btw, we just shipped this breaking change and users of distros that already upgraded are getting annoyed, here is the official way to fix it". tmux IMHO is important enough that talking to them beforehand would have been the decent thing to do.


> tmux IMHO is important enough that talking to them beforehand would have been the decent thing to do

five years ago:

http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux


This seems to be a good example of the Systemd team disregarding user-space developers, if anything.

tmux dev asks:

> If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux?

Which is a perfectly sensible question. After all, what value is there in the systemd team being so resistant to maintaining user space contracts? What technical gain is there in pushing low-level systemd dependencies high up into user space? Wouldn't sane engineering be to encapsulate this kind of low-level platform detail behind libc interfaces like daemon(3), which exist precisely to abstract away this platform-specific knowledge? If the daemon(3) infinite lifetime semantics aren't desirable in all cases, why not add a second call, say user_daemon(3), to address those cases without breaking everyone else?

Zero response from the systemd devs, and 5 years later they change the default to break everyone without following up on these obvious critiques of their design.


If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!"

If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!"

They can't win. Haters gonna hate.


> If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!"

This critique makes zero sense. Encapsulating this kind of thing is exactly what libc is for. What daemon(3) has to do to achieve it's semantics varies by platform. daemon(3) abstracts that away. That's the point of it. Ditto everything else in libc.

Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job.

> If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!"

Again, you seem to not understand the concept of libc and its abstractions.

THere's nothing Systemd-specific about the idea of a user_daemon(3) call. On systemd-using systems it could be implemented using systemd-specific code, whereas on other platforms it could be implemented via OpenBSD specific code or FreeBSD specific code, etc. It could simply be a pass-through to daemon(3) on platforms that don't care about limiting the lifetime of some but not all daemons.

That's what libc is for. It exists to hide the low-level details of the platform from user-space.

Circulating a proposal to extend libc with a new call is exactly what you'd expect from a good citizen in the Open Source community. From a user-space developer's perspective, abstracting away hundreds of lines of dbus calls to systemd-specific endpoints is unequivocally The Right Choice.

That Red Hat seeks instead to push the systemd dependencies as high into user space as possible suggests that technical concerns are not their primary motivation, because Big Ball of Mud style of engineering is bad from any perspective.

> They can't win. Haters gonna hate.

It's reasonably clear that you simply don't understand the critiques being presented here.


> Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job.

Unless those system specific things are systemd specific things, then all people do is complain.

A reply to one of my other comments:

> Systemd is not a platform. And not every Linux runs systemd.

Another reply:

> Didn't know linux also means systemd.

You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though.

> There's nothing Systemd-specific about the idea of a user_daemon(3) call

True, but as soon as a systemd developer proposed adding user_daemon it would immediately become a "systemd" function. As soon as they propose modifying daemon to work with systemd, systemd would be accused of trying to take over libc.

One of the BSDs could modify daemon and no one would bat an eye, apparently OS X did so to play nice with launchd. But "linux is not systemd", so they can't win.


>> Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job.

> Unless those system specific things are systemd specific things, then all people do is complain.

According to you. Although, again, I continue to assert that most people understand that libc is the correct place for this.

>A reply to one of my other comments:

>> Systemd is not a platform. And not every Linux runs systemd.

>Another reply:

>> Didn't know linux also means systemd.

> You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though.

Again, libc is not a homogenous library. glibc need not be implemented the same on all linux systems. Implementing daemon(3) semantics could be done either via systemd or not, as makes most sense on a given linux platform. glibc already does this for other things. The criticism that this makes or assumes all of linux == systemd doesn't apply.

Either way, we'll never know, because the systemd devs did not even bother to try being good actors, here. They're ignoring libc entirely in favor of pushing systemd dependencies up the stack.

edit: I want to take this a little bit farther:

The idea that systemd devs have to push a bad engineering decision (to tightly couple low-level platform details) onto upstream code with no abstractions, which they are being heavily criticized for, was somehow necessary to avoid misguided criticism they might have received for trying to do this the right way, is simply a wrong argument that doesn't make sense.


I don't disagree with you. I look forward to tomorrows systemd hate post:

Systemd developer asks libc to add systemd specific code


But then the haters would be wrong and systemd would be right. Opposite of the current situation.


It seems obvious - if users leave stuff running in the background they should stay running, unless the admin has prevented it or kills it. Seems pretty standard? I don't follow why this is different for systemd.

I'm not wildly happy about adding more OS-specific code to tmux for something it already does perfectly well everywhere (including Linux right now).

If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux?

There doesn't seem to be any discussion following these additional questions from the tmux side. So what you're really saying is that systemd has been aware of the architectural issues with their design for five years, yet have not bothered to fix their end?


> insult to the tmux developers in particular

Not just tmux, every opensource project that used established nohup practices. For example, now all of my virtualbox instances are killed when I logout of Gnome on rawhide. This was a feature of virtualbox that’s worked perfectly for years now.


Sorry, I mean: this ticket filed against the tmux project, is an insult to the tmux devs in particular. Since its directly asking them to do free work to compensate for Red Hat's breakage.

Obviously Red Hat's behaviour in general shows disdain for any devs in any project who had working daemonization code that just got broken.


Where did you get the idea that Zbigniew Jędrzejewski-Szmek is an employee of Red Hat? I can find no evidence for this claim, just a page that says he's a post-doc researcher at George Mason University.


I think it's pushback against what a lot of people see as systemd overreach/arrogance.

"Hey, can you implement and maintain new platform-specific code to work around this problem we're going to introduce by breaking behaviour of programs using a 21-year-old API?"

It feels especially egregious because, as commenters pointed out, implementing the PAM API is a better (and undoubtedly more portable) way to do this that the developers of systemd didn't seem to consider. Instead, they jumped straight to "implement a custom fix just for us so our breaking change doesn't break your app too".


s/"we're going to introduce"/"we introduced"

They already released systemd 230 with this behavior and the bug reports from users of unstable/rawhide sparked the "public" discussion. (The bug report in the link says this right, but it still comes a week after the release instead of before)


If it's a reaction against perceived overreach/arrogance, then those people are just contributing noise to the whole process. People complain about software development in the corporate world being overinfluenced by interpersonal politics rather than pure engineering, but stuff like this is 100x worse than almost anything you'll find in the most toxic corporate environment.

Seriously, every single person who feels compelled to offer their opinion based on what is an emotional response to Lennart's (or anyone's) "overreach/arrogance" is contributing little more than noise to the whole process. It's far too easy for someone who doesn't interact face-to-face with someone else to fall in a trap of assuming the worst about another person when there's a technical disagreement; this is a form of cognitive bias that pollutes development in the corporate world all the time. I'm as guilty of it as anyone, and I've learned to be wary of the temptation to project bad qualities on other people who I disagree with but don't interact with directly.

In the open source world it's so much worse though- not only do almost all developers interact indirectly (i.e. not face-to-face), but there are potentially thousands of people who are basically just casual observers who want to jump in to give their 2 cents. That's great! But it's only great as long as those 2 cents aren't just people bikeshedding, or actively trying to make things personal rather than technical. Unfortunately, more often than not it is bikeshedding, and literally the only thing they have to bikeshed about is to try to make it personal. :(


IMHO this is the root cause: Systemd developers trying to use corporate environment persuading techniques in the open source community.

Instead they should take a step back and rethink their proposed solution every time they get strong feedback or face some resistance from the open source community.


> It feels especially egregious because, as commenters pointed out, implementing the PAM API is a better (and undoubtedly more portable) way to do this that the developers of systemd didn't seem to consider.

I wouldn't consider that bit to be particularly egregious. The thought process of a systemd developer confronted with a regression caused by systemd changing some well-known behaviour would naturally lead to a solution where program X tells systemd that it needs to be handled differently. It's basically a version of the anecdote that experienced developers aren't better because they know the answer to every question, but rather that they know which question to ask. Apparently the discussion has lead to a better solution (not that I would be a good judge of that), so this seems like a bit of a storm in a teacup.


PAM is not portable.


PAM is portable in the sense that it usually exists on Linux systems whether or not they use systemd, and thus is more portable across Linux distributions than systems-specific code is.


The whole reason Lennart started systemd was because to create a daemon you had to have separate init scripts for every distro (i.e., platform-specific code).

So now not only have we not achieved that goal, but now we've inserted an additional layer of complexity into the mix.


Could you please us to this extra complexity you are talking about?


Systemd itself?

It's an entire middleware layer that sits between userland and the kernel that we did not have before.


Er, what does that make init and Upstart?


init systems.


Since you're forcing me to belabor the obvious question just to score some low-effort snark points (thanks!):

The distinction being?

Edit: I'm out of my HN comment quota but kind of glad I am. Because I'm clearly not going to get anything productive from a thread where I wonder aloud why systemd is classified differently and where that distinction lies. When does an init system become middleware "that we didn't have before?" I can think of a few answers but was curious what others think. Fuck me, right?

Instead, ask a question, get snarkily called obtuse and downvoted because we have the misfortune of systemd being the topic of conversation. History shows us you might as well not even participate; if all the people who argued about systemd invested that time into productive activities we'd have warp drive by now. Which would be useful to flee systemd threads.

I swear, systemd is tech's abortion debate.


Stop being obtuse. The GP was saying that systemd has become an entire middleware layer. Instead of addressing that assertion, you were suggesting that upstart and sysvinit are just as much middleware. They're not.


It's the invasiveness or the approach. To use the (wrong) car analogy, the blinker manufacturer shouldn't demand a specific engine oil being used. Amalgamation of components, in the software world, carries long term risk and problems.


To me, the car analogy would be:

For years people have been locking their keys in their car and then having a locksmith open the door when they get back. Now, someone is trying to improve the locks so that a locksmith cant open the door and people are complaining that it ruins a perfectly good arrangement.

In this analogy, 'locking the keys in the car' is 'logging out' and the locksmith is 'nohup'.

systemd isn't really out to break nohup, they are trying to fix the logging out process. Sure, nohup has worked for decades, but 'logout' has never worked right.

The problem is that 'nohup' is designed to 'run a command immune to hangups' not 'run a command even after I logout' and there has never been a distinction between an individual connection 'hangup' and a full user 'logout'. With systemd, there is, and programs don't handle the distinction.

If you don't think there should be a distinction KillUserProcesses can be turned off.


This is the OS level, though - despite the difference in orgs, it's like complaining that Windows is moving away from WCF . Normal coupling rules do not apply.


What is "OS level" though? This breaks user applications, which is three stories above "OS level" IMHO.


It's upsetting because the end result of taking a different approach was because the systemd contributor was told to go "pound sand" and not out of a realization of "oh, I'm actually asking for something bad."

This is an example of one of the concerns people had -- and were told to stop spreading FUD -- about systemd in that it seriously overstepped the bounds and desires of an init system.


the systemd contributor was told to go pound sand because it's a different flavor of a question that systemd folks have been asking nicm for 5 years now. After having the same conversation over and over stating your same reasoning to deny the change, you'd probably tell people to go pound sand too.


I believe you misread me. I'm glad nicm refused to add to the Rube Goldberg machine.


Oh totally. My apologies.


It's not "platform specific code", it's breaking historical behaviour.

Killing user processes after logout (when they have been set to not do so, through nohup usually) is not sensible.

Edit: clarification


Killing user processes which aren't meant to stay alive after the user logs out is sensible. Killing all user processes unless they update their code to implement a new API just for this one platform, because of a breaking change to a 21-year-old API, is not sensible.

In other words, if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided and we'd all be happier, but since it didn't the systemd guys are trying to implement it retroactively, which is going to break a lot more stuff than tmux/screen/etc.


Killing user processes which aren't meant to stay alive after the user logs out is sensible

Only if you can succesfully determine which ones the user wants to keep running. Otherwise it's just breaking stuff, as this story shows.

if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided

Not really. You will always have sub-standard software that doesn't adhere to the system's declared semantics, and just goes by "what works" (ask the WineHQ guys). Any API that has been around for 21 years will have corner cases where software just breaks. That does not mean you're then free to break the old API yourself.


I'd like to respectfully disagree here. IMHO, killing user processes after logout is totally reasonable and something I would expect to happen on desktop computers. On servers this might be a bit more difficult, but I like the idea of having to explicitly allow user processes to run outside of the session's scope. That keeps my server used by multiple people clean. I'd argue most sysadmins could simply deploy an alias to their servers for specific applications and be done with it.

edit: If you're already using a specific command to tell the application to stay alive (e.g. nohup), you can use the "new" systemd command as well. nohup never related to a "session" scope because that didn't really exist before systemd. A new command _does_ break historical behaviour, but thanks god we do that from time to time. That's how innovation works.


> killing user processes after logout is totally reasonable

How is it so? I cannot see a single legitimate justification for such a stupid behaviour.

> "session" scope

Exactly. There is no such a thing, and it should not exist, it's a totally alien concept to anything Unix.


Sure there is, that's why nohup had to be invented, because people wanted to leave some processes running after logout.

(By the way, I disagree with this request to change tmux)


> after logout

Not after "logout", but after terminal is detached. For whatever reason. There is no such a thing as "logout".


  When I log off (by giving the logout command) the shell will print ‘logout’ and
  execute commands from the file ‘.logout’ if it exists in my home directory. After
  that the shell will terminate and UNIX will log me off the system.
- Bill Joy, An Introduction to the C shell (1978)

The concept is commonly called logout, even if you prefer to call it something else.


That written in a world where you had one terminal on your desk or one modem to dial into the system.

If you had two logged-in terminals on your desk and ran 'logout' on one of them, are you still logged in?


And thus we are back at square one.

Dbus devs apparently asked themselves the same, added the concept of a user session to dbus alongside the existing login session.

Gnome code happens to get the two confused (or dbus fails to properly tell one form the other, likely by mixing old and new behavior).

Systemd dev notices leftover Gnome processes, and convince Poettering to flip the safety on the big gun.

All this while giving crap all about unix conventions...


Sure it is; we do it all the time. When a TTY quits, everything in the process group attached to that TTY is sent a signal to quit; this is the original point of SIGHUP. A systemd session is a generalization of that concept, where the "terminal" is anything someone has logged into—a terminal session, or an SSH session, or a GUI session. Sort of a process-group-group. It tries to retain these semantics.


While ignoring the hell out of the actual mechanics, thus breaking behavior that has been with *nix for decades.

What you are describing is systemd becoming a kernel sitting on top of a kernel, second guessing the actual kernel.


[stupid discussion. deleted]


> If you really need to run longer, tell it to the system.

... with nohup. Which now doesn't work.

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


nohup (no hangup) just concerns itself with the controlling TTY of a process. By running "nohup", you are not passing on the intent on why this process should be kept alive, and for how long. Traditionally the answer was "forever", but I think it's reasonable to implement lifetimes "for this session", "once the last of my sessions has ended, probably after a timeout" and "forever".

(Added:) The first runtime, in systemd parlance (I think), would be the session scope, the second runtime would be the user service and the third... well, something different, as you'd pass on things (group memberships, environment variables, namespaces) from your shell/session into a long-lasting service. One probably would want to extend the "once the last of my session has ended" state to the runtime of the "run forever" command.

Most non-technical users, I guess, would really prefer one of the first two lifetimes to be the default. As being able to start from a clean state after logging in- and out is rather convenient.

As nohup, in an interactive shell, is used for the third "keep running forever" option, I think it would be reasonable for distributions to alias it to the relevant "systemd-run..." command for all default shells. Then user-expectations would be perfectly met (and scripts will still run the binary /usr/bin/nohup).


How did they justify breaking nohup? I thought it was a common usage pattern to nohup long running jobs before logging out.


Expect them to call it a broken concept, as they did with su.


Yes, when you want a process to continue to run when it's controlling terminal is closed you ignore SIGHUP.

> and no, unix signals are not a sane API

It might not be modern, but it's stable, widely used, and incredibly well documented. Hell, systemd is implementing this behavior using signals.

> Breaking with historical behavior is called progress.

It's not historical behavior when applications are today being developed that rely on said behavior.


> Breaking with historical behavior is called progress.

Progress is building upon the best practices of the past, not breaking things because a bunch of very low quality, uneducated "developers" who all came from an alien culture simply could not think of a better, idiomatic solution.


> very low quality, uneducated "developers" who all came from an alien culture

This is the level of discourse I've come to expect from any discussion related to systemd


>Breaking with historical behavior is called progress

I think the problem people have is that systemd developers seem to actually believe this axiom.


Yes, it's quite sad how unconciliatory the two camps (systemd implementors on one side, the traditionalits on the other side) have become. Both sides' arguments have their merits, but with this unnecessary hate and anger everywhere no one really wants to join the discussion anymore. :-(


You're asking people that were here before systemd and argued quite deftly against systemd's takeover of Linux to now "have a conversation" about systemd's further encroachment.


Why should we even talk to them? They're invaders. They must be exterminated.


Well, do you know the init-wars? That's the result of polarizing people. A lot of them won't do you a favour, just because they read your name. Even when it may be a reasonable choice, from a technical perspective.

Seeing such an emotional reaction so long after the war makes me wonder if systemd can survive in the long run, though.

Seems to be an issue of "The north remembers."


As an open source maintainer, I see requests like this quite frequently, and almost wholly are poorly thought through requests. Library specific code has a lot of negative ramifications, and almost never is worth it.

Requesting the specific desired feature/fix is almost always preferable.


A surprising and troubling comment in the github comments: "Honestly, I don't see why processes should be able to decide that they should run forever."

I actually let slip an f-bomb reading that. It shows a terrible understanding of longstanding unix philosophy, (and also straw-mans the argument).

Happily, it doesn't seem that was from a systemd developer as far as I can tell from their website. Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie.


> Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie.

This is a very relevant remark and highlights the root of the entire discussion, I believe. There seems to be an ideological fault line here. And I think, it is between those who wish for some ideal, all encompassing design and those who have been burned by the short sightedness of such ideals. Grand engineering ideals cemented into closely knit structures are really great on paper. But some years down the line, you realize you have made too many commitments, optimizing for something not relevant anymore. And now you have to circumvent all those greatly engineered structures. It's a bit like looking at satellite cities, the visions behind them, and what has become of them.

The Unix philosophy is mostly about avoiding those pitfalls. But I guess, understanding this might only come with experience.


Totally, this is put better than I could have, but is exactly how I feel watching and experiencing the systemd thing play out. I'm old enough now that I (I'm such a nerd) don't really want my init system messed around with, but I do get there may be better ways in general.

In practice though, to me that would mean something that while looking pretty and being better automated would come with many fewer hidden parts and many fewer interactions between parts than sysvinit. That is, I'm looking for simplicity, composability, editability.

The implied technical debt of one system to rule them all is a lot over 20 years, and you will inevitably have to get into line with a dominant system as a developer downstream from it.

At any rate, happily this behaviour was publicised enough that I won't spend a day googling it when it happens to me. :)


> Totally, this is put better than I could have, but is exactly how I feel watching and experiencing the systemd thing play out. I'm old enough now that I (I'm such a nerd) don't really want my init system messed around with, but I do get there may be better ways in general.

Thanks. I'm kind of in the same boat, age wise. I have the impression (and this comes from a number of comments online and a podcast with Poettering I listened to lately) that any criticism from the experienced crowd is seen as a sort of elitism of people entrenched in their abilities they honed over many years. This might be the case for many critics, and Poettering may be right to dismiss them. But I'm afraid that the very valid criticism regarding overall design goals is lost in all of this. The systemd team steams on, believing that all naysayers are just stuck in their ways.


The way i see it is that systemd developers are coming at it from the DE down. This while unix systems are pretty much constructed from the kernel up. You get the kernel going, then you get CLI userspace going, then perhaps you get X going, and only after all that a WM or DE.

This means that if the DE or X develops a fault, you can always fall back to the CLI to get it back up.

But with systemd, the CLI has become subservient to the DE.


That's interesting. And, of course, the linux desktop environment (other than android) has not had the best story in the last twenty years, so maybe you do have to come at it desktop first.

I really like my CLI though, and really really want to be able to change anything about my system from vi if need be, so I guess I fall on the other side of that perspective.


Meh, i think the problem of Linux DEs is not the DEs themselves but having to face of against Microsoft where they are strongest.

Android got in the door by Google convincing the OEMs to switch Window Mobile for Android, with Google carrying the brunt of the development cost for free.

This happened just as MS was running around in a panic and managed to split their mobile platform in two with Phone 7.

In contrast MS bent over backwards regarding netbooks. They had started shipping Vista, and yet they gave XP another reprieve on execution when Asus started shipping their Linux powered EEEPCs.

Only with major cockups regarding Windows powered warships, and having a former general as chairman of the board, has Red Hat been able to get on the DoDs good side.


I don't see how the process are even able decide to run forever.

They can decide to die when they lose the terminal on SIGHUP (or on any other event), be nicely asked to stop with SIGTERM, and surely can be forced to die with SIGKILL. Everything is there for decades, sane and simple - so I don't really get the idea.

I mean, if some process hadn't considered dying on HUP (i.e. on session close) while it should - it's a bug in that program, go ask its author to fix it.


Well, you can be written in such a way as to not die unless you want to (try killing a program reading from a disconnected NFS mount..) but I agree it's a strawman argument.

In fact, the question is should the shell and init environment overrun the (at least 30 year) unix convention that a user's background processes are not killed when they log out?

The reasons given for a 'yes' answer to this question had better be well and truly good, from my perspective. It's not nearly sufficient to say 'some users complain that things are running when they log out'.

If you read the original bug report, this all started because some userspace programs aren't very well behaved, and the typical windows or os x behaviour would be to log out, ensuring the OS kills them, then try them again.

Generally the advice from unix land would be:

1) Don't use those programs 2) Learn to use ps / top and how to kill a naughty process 3) logging in and out is meaningless when it comes to things running as daemons or in the background.

It's pretty shocking to me that someone thinks the best solution is to obviate all that advice. Not that users won't get an experience they expect from other OSes -- they will. But many users will lose a simple experience they rely on, even if they never touch the GUI. That has a bad architecture smell to me, and I think some other solution could be found.


"tmux is not going to use dbus"

And that is why I use tmux.

As a BSD user I started using tmux as soon as I saw it imported into pkgsrc in 2009. What a pleasant surprise it was, I remember well. I live in textmode and everything about this program's design was appealing to me immediately. I am very fussy about software and that is rare. I was so excited I even emailed the developer with a dumb question, which is not something I do very often. He's an OpenBSD committer. Surprise.

At that time there was virtually no online discussion of tmux that I had seen.

In the graphics dominated world we live in, I am amazed at how popular tmux has become.


Its because even though most personal computers have a GUI, most of the development and configuration of the internet happens via text.


Because a project should never have platform specific code.

  justin@t420:/tmp$ git clone https://github.com/tmux/tmux.git
  justin@t420:/tmp$ cd tmux
  justin@t420:/tmp/tmux$ wc -l osdep*
     95 osdep-aix.c
     88 osdep-cygwin.c
     80 osdep-darwin.c
    133 osdep-dragonfly.c
    202 osdep-freebsd.c
     41 osdep-hpux.c
     98 osdep-linux.c
    137 osdep-netbsd.c
    157 osdep-openbsd.c
    101 osdep-sunos.c
     41 osdep-unknown.c
   1173 total
Apparently people have been trying to get tmux fixed for FIVE YEARS NOW

http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux


tmux is able to contain the platform specific code to a single file per kernel? How quaint. They must really care about reusing existing platform abstractions such as daemon() from glib instead of bloating their codebase pointlessly. Good on them.


I am not sure I get your point.

Systemd is not a platform. And not every Linux runs systemd.


> Systemd is not a platform. And not every Linux runs systemd.

For now...


Didn't know linux also means systemd.


Can't wait until

  osdep-linux-sysvinit.c
  osdep-linux-openrc.c
  osdep-linux-upstart.c
  osdep-linux-systemd.c
  osdep-linux-epoch.c
  osdep-linux-finit.c


Welcome to the future


So it's fine to support FIVE different bsd systems (darwin, dragonfly, freebsd, netbsd, openbsd) but one needs to draw the line at better supporting the init system used by every major linux distribution.

Okay.


The BSD systems have had 20+ years of divergence. There are areas where they'll borrow from each other when one of the others has a tool that works better than the status quo, but the kernels are vastly different animals. When a BSD does make a world-breaking change, like pledge(), it owns it, and will patch software itself to handle it, not pester upstream to stop what they were working on to implement their special snowflake code, which is what the systemd developers want to do.


Those BSDs are completely different kernels. Init system is userland. Linux is still one kernel, last I checked.


Cast your mind back to when SIGHUP first started getting sent to processes on logout. Some programs had to start making an new API call to block SIGHUP killing them. nohup was invented. Some admins probably disabled SIGHUP for a while as it sorted out, and some probably called for these kids and their newfangled signals to get off their lawn. So it goes.


> Cast your mind back to when SIGHUP first started getting sent to processes on logout.

That would be before 1979. nohup was in 7th Edition. I haven't checked 6th.

Ironically, by pointing to the fact that one has to go back through 37 years of documentation, education, user experience, and scripts you are making other people's point for them. Especially by drawing attention to one of the major flaws in the "nohup was new once" argument, which is that in 1979 (or before) there wasn't a prior 37 years built up to contradict. (-:


I was curious what the oldest reference of it was,

https://github.com/dspinellis/unix-history-repo.git

has different branches for various unix versions

Seems the earliest reference I could find in there was dated november 1973, but it is from a full import in 77:

commit c849507974bd2c0e2fd8c17e06f6f65b68075ca9 Author: Bill Joy <wnj@ucbvax.Berkeley.EDU> Date: Wed Nov 23 12:43:50 1977 -0800

    Start development on BSD 1
    Create reference copy of all prior development files
    
    
    Synthesized-from: 1bsd

Some of the earlier copies i can see were even just shell scripts:

  trap "" 1 15
  if test -t 2>&1  ; then
	  echo "Sending output to 'nohup.out'"
	  exec nice -5 $* >>nohup.out 2>&1
  else
  	exec nice -5 $* 2>&1
  fi
Research-V3-Snapshot-Development did not have nohup Research-V4-Snapshot-Development had the nohup man page but not nohup Research-V5-Snapshot-Development has nohup.c

commit 0281f55d1cf7aa94555d8522d8b37161b97791be Author: Ken Thompson <ken@research.uucp> Date: Tue Nov 26 18:13:21 1974 -0500

    Research V5 development
    Work on file usr/source/s2/nohup.c
    
    Co-Authored-By: Dennis Ritchie <dmr@research.uucp>
    Synthesized-from: v5

Then later v7 reverted back to the shell version

commit 6144d5b3a973b515977eef01a828cdd82c480fe3 Author: Ken Thompson <ken@research.uucp> Date: Wed Jan 10 15:25:04 1979 -0500

    Research V7 development
    Work on file bin/nohup
    
    Co-Authored-By: Dennis Ritchie <dmr@research.uucp>
    Synthesized-from: v7


The title is fud. The developer mentions "systemd-run --scope --user tmux" will work just as well. tmux could add this in its default to make it run automatically.

This is due to a larger discussion that most users don't expect lingering process after logout. https://github.com/systemd/systemd/issues/3382 In these situations, screen/tmux must include changes that enforce this behavior. Today the operating system itself does not reap processes ... but systemd is not doing anything wrong. By adding this change, tmux/screen users will still get the behavior they expect and the rest of the world get a better behaving operating system.


> but systemd is not doing anything wrong

It's breaking historical behaviour

However making tmux try to use systemd-run is a much better solution than making it depend on libsystemd


the libsystemd dependency is the goal systemd is trying to achieve though, in every package.


[stupid discussion. deleted]


I'm sorry, but the list of packages out there with a libsystemd/libsystemd-* dependency is massive. I'm not just talking about this specific use case.


Yes it's breaking historic behavior - but it's taking care to bring in better behavior by trying to . maintain backward compatibility.


It's breaking historic behavior that works. What's going to happen 5 years from now when we have misbehaving programs that do exactly what the systemd folks are wanting the tmux folks to do? Are we going to start seeing a systemd-really-really-keepalive? The solution is to change the misbehaving programs, not break the programs that already work.


> most users don't expect lingering process after logout

You might want to see all of the people at https://news.ycombinator.com/item?id=11782364 who are expecting nohup to effect exactly that, with reference to the Single Unix Specification no less.


It's doing something very wrong. They are using this as a sledgehammer to solve a gnome issue.


> most users don't expect lingering process after logout

Who should ever care about the opinion of the non-contributing, useless users coming from the irrelevant platforms?


Still, seems like this should be done at the distro package level. I know it's more work for maintainers, but that's part of the cost of choosing to support systemd, and should have been taken into account when that decision was made.

(Btw, I'm ambivalent on systemd itself)


> Still, seems like this should be done at the distro package level.

This can be done at the distro package level. Packagers would edit /etc/systemd/logind.conf and set KillUserProcesses=no to disable it. It's a single line change if people don't like the new default. The behavior itself (killing user processes when the session ends) is quite sensible, and should have been the default over a decade ago, but people got used to terrible defaults and are now complaining.

This is handled at the packager/admin level, but they merged a patch two days ago (https://github.com/systemd/systemd/pull/3373) to fix the policy to let users manage it themselves with loginctl enable-linger. I think it missed the v230 merge window, but could easily be backported individually or at the distro level until the next release.

So, not only can the behavioral decision be managed entirely at the distro level, that decision can be punted down to the individual user if they don't want to explicitly mark the processes they want to continue running.


What I'm saying is that this exception should be added to tmux at the distro package level, they shouldn't push to have it included upstream.

In any case, wasn't killing user processes already the norm except for the ones which called daemon() or equivalent? And won't the new system kill user processes except for the ones who call StartTransientUnit? I'm having some trouble understanding the improvement, except for the short-term gain until the broken processes start calling the new API.


It will be modular they said. It wont be invasive they said.


To reiterate something I just wrote in another post:

Whatever you think of it, systemd is doing the "ground-up rewrite" correctly. Normally, you get 90% of the features for 10% of the code in a rewrite, but then the last 10% of the features are the "plugging this thing into the ecosystem of other crufty things" features which bloat the codebase into something exactly as bad as the original.

The only successful way to do a rewrite is to scope your rewrite not to the size of one component, but rather to the size of the whole component ecosystem, such that you get to redefine all the crufty boundaries requiring convoluted code into clean and simple ones. This means you do have to rewrite more things, but each one can stay at that 10%-for-90% size, because none of the bad-API bloat has to come along.

systemd is consuming components of the Linux userland and leaving cleaner boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before.

People also forget to compare the functionality of the entire ecosystem of software—not just the big stuff everyone uses, but the niche stuff—before and after. Linux's original bazaar approach to system software meant that everything worked with whatever components it explicitly planned to work with, and nothing else. Do you know how many codebases contained some random subset of support for logging via STDOUT, logfiles (with or without rotation), syslog, rsyslog? That's what you get with a bazaar approach. systemd's "hub-and-spoke" cathedral approach means that everything just has to work with systemd, and then systemd can ensure that everything works with everything else.


Exactly.. The most amusing thing about this is people claiming they are going to switch to a bsd. As another said on the other thread:

> I really dislike the idea of having one project handling everything on a box

Which is crazy talk because that is one of the selling points to something like openbsd.


I get what they mean and its not really crazy talk. The difference between a project in the sense of systemd and project in the sense of OpenBSD is pretty big. If I told you that wget was requiring changes to all user behavior, you would laugh it off and wonder where they got the agency to demand that. Many folks view the people with such agency as the kernel developers and the GNU project not a project such as systemd. They are probably wrong these days. This is different than the pick of a BSD.


Meanwhile openbsd adds pledge(2), patches most of their userspace to support it, and is praised across the board.

If linux tried to add pledge you'd have people coming out of the woodwork claiming that linux was breaking UNIX and requiring "linux specific" patches to every project.


Well, first, its pretty much in the DNA of OpenBSD to try security implementations like pledge.

Second, and much different from what SystemD just did, pledge does not affect any program that doesn't use pledge. From an external caller point of view, each changed user land program should act in the exact way that it did before the change.

A programmer can safely ignore pledge and nothing has changed for them. A user can safely ignore pledge as it shouldn't change their usage.

If Linux (I would guess more appropriately the maintainers of the GNU user land) tried this under those conditions, it would still be an internalized change that shouldn't affect anyone outside the project except in the positive as an exploit mitigator.

The bottom line is: OpenBSD is not requiring changes in other developer's programs or in user usage to continue to run in the same way they have run in the past.


My understanding is that programs which don't call pledge don't break under openbsd, they just don't get the corresponding security improvements.


Pledge was not praised across the board for precisely the reasons you mention. It's optional so no one aiming for portability will implement it, it's not user configurable, permissions are too broad, it's unusable by any application that isn't pledge-aware, etc..

Now SELinux isn't perfect by any meaning, but the key difference is that applications can be SELinux aware if they choose, but you can still have full protection without the application knowing that it exists.

I would much rather try to improve SELinux than try to make pledge work for precisely this reason.


It is also the reason why most common advice is to just turn off SELinux. It blocks valid (although sometimes weird) usage, because someone else decided that 90% of users should not do something.

Developer knows better what program should and should not do and is much more capable to set this kind of rules with pledge.


Lets not forget that SELinux came out of the defensive side of NSA. Its to block attacks to government systems from both outside and inside. In essence it is the concept of "trusted computing" given form.

And that concept in turn means that a general can put a trusted system into hostile territory and trust it to not leak secrets.

And NSA still care for it. Around the time of the last kdbus dustup, someone from NSA voice a worry about how kdbus would compromise certain parts of SELinux.


They can patch in their versions of tools as much as they want. And if some third-party project doesn't want to integrate pledge it works just as well as before.


Unfortunately this includes rewriting tools that have scope beyond your ecosystem.

Many of these tools have to run in other *nix. Tmux came out of the OpenBSD community. Why would they necessarily want to put in effort to make sure your house is built correctly?


I left Linux for BSD on my home computers. FreeBSD has the right mix of OS aesthetics and great practical tools. Between the new binary pkg tool, ezjail, and great native ZFS support, I am very happy with it.


Did the same to our entire server stack (20+ servers). We were using Ubuntu and Upstart, and when Debian announced systemd, Ubuntu announced the end of Upstart. Having to move all our init scripts sucked, and while trying to select the best approach, the systemd war was just getting started. A friend who was hearing me weigh the merits of different approaches suggested FreeBSD, and I'm not sure why I hadn't considered it prior. We moved to it (a couple years back) and it's been a breath of fresh air. Even better, I can watch the systemd takeover from afar.


I made the same move, except I added an extra piece.

Instead of moving everything to a new platform-specific init system like freebsd's rc system, I instead moved everything to runit. Runit can run ontop of an existing init system, so now I can have this code running ontop of bsd, upstart and systemd based systems without having to change a thing. It's really be a savior for me. I don't touch anything, I write scripts that are about the simplest thing I've ever seen and it just runs anywhere I toss it. I used to avoid writing init scripts like this like the plague but runit has made it quite enjoyable. I've even moved a lot of dev stuff where I had everything running in tmux to runit based control.


As a newcomer, FreeBSD's new pkg tool is what sold me to the platform. I am too new school to to deal with Ports. I don't get much of a rush out of compiling my own binaries.


Does it offer something beyond OpenBSD's pkg tools?


A database backend which makes searching through packages, and occasionally being naughty and altering manifests, easi. It's fast as hell, like faster than apt, it lets you lock packages to a specific version, etc, so you can do things like have 2 or 3 packages built with special flags and still use the package management tools. It's fantastically clean too and well documented, as BSD software tends to be.


systemd has turned Linux into a tire fire.

I've spent 20 years with this platform and seriously worry about it being as useful the next 20.


I feel the same way about network manager. Maybe it's just me, but I am not a huge fan of nmcli.


You can just uninstall it and use something else to configure networking. It's one of the first things I purge on any distro.

With systemd it's not so simple.


What do you replace it with?


All of my debian systems have their network configured with /etc/network/interfaces like so:

    iface wlan0 inet dhcp
        wpa-ssid redacted
        wpa-psk "redacted"
It's a bit clunky if I need to take a laptop around to different wifi networks, but I don't do that very much.


I use wpa_supplicant on Debian, it has no problem associating with many different wpa-psk networks. I think it can also do wpa-enterprise, but haven't needed that yet.


Personally, I replace it with connman[0], as I find connmanctl(1) to be far more usable than nmcli.

[0] https://wiki.archlinux.org/index.php/Connman


systemd-networkd

It actually works rather well but it doesn't have every feature that NetworkManager does.


I use netctl and find it works very well.

For non-wifi use cases you probably don't need anything at all (maybe dhcdcd).


I use wpa_supplicant + dhcpcd + wpa_gui and only have to update my config like once per year.


networkmanager is a shocking mess, when you look at how simple this functionality is in the *BSDs.


by "this functionality" do you mean things like

* connecting to different wireless networks that use wpa enterprise authentication (which I think some of the bsds only recently added support for)

* bringing up usb networking interfaces via cell phone tethering on demand

* managing multiple different vpn clients and profiles from a single interface

Or do you mean things like

* Bringing up a networking interface with a static ip address

Because I use network manager for the former on laptops, and remove it on servers that only need the latter.


The former.

As with many things, yes, it took OpenBSD and FreeBSD longer to get that functionality. The tradeoff is that they delivered a well thought out, consistent, and well-engineered solution, rather than a poorly thought out mess of CADT-driven bloat.


GENTOO has sys-fs/static-dev. With some effort I have server running without systemd, without udev, d-bus, pulseaudio ... plus not compiled support for ipv6, nls, ldap, etc.


You could have saved yourself the effort and installed a linux distro from 1999.


Yeah, some 32-bit one that predates SATA and ships with 20 known remote vulns.


How has systemd effected you?


It broke a few of my Arch installs. I had to learn a bunch of new tools which didn't improve my work in any way. The only things that it made easier were things that were already easy.

More importantly, I think that some of the systemd maintainers have a track record of not really knowing what they're doing, as exemplified by this tmux issue. I have serious worry about running their process as PID 1.

Other than that, totally positive effect: It deepened my interest in OS security and hastened my switch to OpenBSD which was probably happening anyway.


Arch is an interesting choice of distro if you value stability


For me, Arch very rarely delivered "omg nothing works" moments on upgrade for me. The only one that I can think of was the systemd upgrade. For every other breaking change, a fix was either easily apparent or well-documented on the wiki.

"Stability" in the sense that OpenBSD provides though is something that I valued more over time of running Arch and my experiences with other things on the side (mainly QNX).


Arch is largely OK. The only troublesome and WTF-ish upgrades I recall were systemd (which I avoided) and symlinking of /bin and /lib to /usr.


Technically I appreciate much of the systemd design and implementation, but what repeatedly annoys me is when it 'takes over' - replaces - existing tooling and doesn't provide feature parity, resulting in regressions.

The one that really annoyed me (and is still present) is when it replaced cryptsetup init scripts but did not implement support for root file-system key-files.

For release-upgrades this will result in broken, unbootable, systems - it isn't difficult to imagine how this causes swearing and bad feeling!

For new installs it means loss of required functionality, and lost time and productivity exploring and implementing work-arounds to counter the regression and return to the status quo.

The reason for the lack of key-file support in systemd-cryptsetup? The purist idealism that key-file support patches will only be accepted if they use the Linux kernel's key-ring API (rather than replicate the existing cryptsetup init script behaviour).


By making many of my systems totally unbootable after an upgrade?


Systemd created him?


It's important to remember that it's not "those systemd guys" who are breaking everything. It's their backer, Redhat. Redhat is leveraging its strong position in the free software ecosystem to bend all Linux distributions to its way of doing things. I think they're mostly guided by a desire to keep Canonical penned-in and in a defensive position.


Redhat funds almost every kernel developer there - including several core libraries and security.

Canonical does not spend so much on employing core developers and feeds mostly on upstream.

That in itself is not a problem...but your presumption is wrong. If you track the systemd inclusion process in Debian, you will find that it was not subverted but was a free and open fight. Systemd won on its perceived superiority by people much smarter than me.


That's not quite it - it "won" because the Debian project only has the time and people to support one option, and they got railroaded.


That's not quite correct though: all of my Debian systems (jessie and stretch) are happily running with either sysvinit or openrc. Maybe there's a problem running Gnome without systemd, but I'm not using that anyway.

The only thing the TC decided is that daemons must be able to run under systemd -- which can be achieved by providing a (cross-init) sysv script, or a systemd service file.


I am not sure what is your definition of "won". There is only one option can be supported, and debian picked systemd over other options. It seems exactly fits the definition of "won".


Perhaps you should re-read your Thucydides, specifically the Melian Dialogue.


I'm making no defense of Canonical. I'm not an Ubuntu user. Redhat has been doing the right thing for years, with paid employees in prominent positions throughout the ecosystem, including the kernel, as you note. The problem is that they've taken all that goodwill and soft power and weaponized it to back GNOME against Unity.


Frankly i think they are more worried about Oracle than they are about Canonical.

While RH and Oracle has a long history of cooperation, Oracle now have their own distro thats a fork of RHEL.

This fork prompted RH to end some policies that made life easy for CentOS (who now happens to be sponsored by RH), regarding the packaging of various patches.


Canonical does the same thing though (Mir).


They're the same class of jerks, but they don't have the leverage to strong-arm everyone the way that Redhat is doing it.


Frankly i see Canonical being a lesser issue. They are doing basically the same that gave us the various BSD flavors.

They are not tying together originally independent projects so that others has to conform or else. They build their own thing to their own needs, and if you find you have the same needs then your free to help out.


Also getting things done your way instead of the reasonable way can save a lot of money in the short term, and a huge part of business is exactly that. It's not nice, but you can't survive in business if you don't use leverage to make things easier sometimes.


> breaking everything

This behavior can be disabled by the distro or admin with a single line change, and there's a policy for users to be able to set the behavior for themselves with a single line. They fixed a problem with that policy two days ago, but the fixed policy could be backported for those who need it immediately before the next release. This is in addition to being able to control it on a per-process level. Obviously they gave us so many ways to control this because they wanted to break things.

"Breaking everything" is nothing but hyperbole. This change won't make it to the users unless the package maintainers just let it through. And I can guarantee after this stink that every systemd packager will be informed of the decision.

Yes, asking tmux to request this behavior by dbus was amazingly short-sighted, bordering on stupid. I don't think anyone really wants to argue that. Plenty of developers get caught up in the importance of their project and fail to recognize that not everyone else wants to use it. So he's easily earned some criticism.

I suspect it was well intentioned; he probably heard people complaining about how this change affected tmux, and wanted to help people "resolve it". He obviously didn't understand that this is not the way tmux would want to handle it.

> Redhat is leveraging its strong position ... to bend all Linux distributions to its way > guided by a desire to keep Canonical penned-in

This reactionary stuff is completely out of hand. We have people:

* claiming that the default should always be to let everything run forever because that's the way it's always been isn't much better. Since the moment Linux supported multiple users, letting processes continue after logout was a bad default. * insisting that any compiled code beyond the absolute minimum in the boot process is a bad idea. * Insisting on bad faith when developers don't consider their singular workflow. * Stating that standards don't matter if only one system implements them. Despite the fact that most standards start with 0-1 implementations. * engaging in constant tinfoil hat conspiracy claims against Gnome, Redhat, and any other group of contributors larger than 2 people. Obviously they're trying to control us and not, you know, trying to make things work the way they want to work. The fact that these corporations fund major portions of the ecosystem and contribute heavily to all levels of the stack doesn't matter anything - they're obviously trying to get a "monopoly" on linux through open source code. Or working with the NSA. Yes, someone's actually said that.

It beyond ridiculous to think that there's anything guiding these decisions other than the perception of what makes a good product to those involved. They might be wrong, but they're not malicious.

It's disgusting that these systemd threads always spiral out of control like this, stirring up a disturbing level of vitriol. We have constant mudslinging over things that can be fixed with default configurations at the distro level. The fact that we still have these periodic flamewars and monthly hatefests about any groups or projects (even systemd) makes working in the FOSS community an undesirable minefield. We should be embarrassed as adults that we lack the self-control to deal with this in an adult fashion.


I cannot believe how many people are arguing that they are 'fixing a problem' or 'adding new functionality' here. They do neither of those things; and I really hope none of the guys who argued that are writing code in their day job - sad enough those systemd guys that came up with this hack do!

The old state of affairs is dependent processes are killed by default on log-out, but there's an opt out method.

The new state of affairs: dependent processes are killed by default on log-out, but there's a new opt out method.

The only difference is the old opt-out method is now ignored, in order to reap the misbehaving Gnome processes that use it - until of course those processes adapt to the new API or some other processes do something similar, and we can start the game anew, instead of ever fixing the misbehaving code...


I'm sorry but this is reasonable. Systemd is fixing real issues with Linux, and if apps rely on old bad behaviour they should be changed to work the new better way.


> apps rely on old bad behaviour they should be changed to work the new better way

This behavior is neither old nor bad and painting it as such is just rhetoric.

When the 'session' that spawns a user daemon ends, usually via logout, the child processes receive SIGHUP which notifies them that their controlling process has exited. Most processes respond to this signal be terminating. However, if a process is intended to persist, then it will simply ignore the signal and continue running.

Now, if we're going to have a rational discussion about this then you need to explain what is wrong with this model, and why transitioning to a systemd specific dbus interface is an improvement.

> new better way

Which has a hard dependency on a specific init system reducing portability. UNIX signals are stable, documented, and so portable you can even use most of them on Windows.


The problem here, though, is that they're requesting programs which used to be able to persist via call foo() to call bar() instead if they want to persist on logout, only on Linux.

As someone in the linked issue remarked, this will end with everyone calling bar() if they want to persist (the same way they already called foo()), and we'll still have the same level of persistent process issues, but with a systemd dependency.


> but with a systemd dependency.

Worse, this isn't "the systemd developers have proposed a new common API for simplified persistent processes across platforms", but a hard dependency on this particular revision of the systemd dbus interface, or using the systemd-run application to generate a user service file.


Best explanation of the core issue thus far.


Correction: it's working on "perceived" issues with Linux, e.g. plaintext logs being too large or sequential boot processing being too slow.

I personally don't think that systemd and subverting unix philosophy is worth the trade of faster reboot times on my servers. It solves a "problem" that I don't have with a middleware solution that I don't want.


> sequential boot processing being too slow

I have a eight-core CPU. Do I want to wait 80 seconds waiting for my laptop to boot because it is using only one core of CPU? Or do I want to wait 20 seconds waiting for my laptop to boot using all the cores available? I do not know what your use-case is, but to me, the choice seems pretty obvious. Can you provide any reason why it is a "perceived" issue, not a real issue?

EDIT: 80 seconds or 20 seconds are not the hard numbers, these are just used to show 4x speed-up on 8-core CPU. Also, why the downvote? Is HN becoming another echo chamber where people can not accept different opinion without downvoting?


That's assuming that booting is CPU-bound. However I am fairly confident that for over 90% of people it is IO-bound in which case throwing more CPUs at the problem won't make it go any faster (might even be slower).

And for reference I have compared sequential vs. parallel on rotating disks and SSD for myself. And there was almost no difference in boot time between both (only significant speedup was from replacing the rotating disk by the SSD).


It's a "perceived" issue because not everyone has written his/her init scripts in a way that cause a boot time of over a minute. Or have uptimes in the magnitude of years, or if using Linux as a desktop OS, aren't pestered by the extra handful of seconds.


As I have said 80 seconds or 20 seconds are not hard numbers, just used as an example. It can simply be rephrased as 4x speedup. I am not sure how the uptime argument is relevant here.

> if using Linux as a desktop OS, aren't pestered by the extra handful of seconds.

Your last point seems argument for the sake of argument. We are in a technical discussion, not a religious discussion. I did not buy a 8-core CPU to wait extra seconds paying electricity bill for the unused CPUs to validate someones hatred for some specific init system. If systemd can better utilize my system resource and cut my waiting time, I am going to use that. My lost time is the real issue, someones irrational hatred for something bears no value to me.


> I am not sure how the uptime argument is relevant here.

Init-time amortized over uptime. 5 seconds to boot is a big deal for a box that comes up, lives for 60 seconds, then dies. Not so much for a box that comes up in 5 seconds and stays on for 2 years.

> Your last point seems argument for the sake of argument. We are in a technical discussion, not a religious discussion.

And yet, you're making up numbers to paint a picture you want others to see. You suggest that I'm arguing from opinion when you're making up details because you want to be seen as correct.

> If systemd can better utilize my system resource and cut my waiting time, I am going to use that. My lost time is the real issue, someones irrational hatred for something bears no value to me.

Then use systemd. Or don't. This is what I meant about "perceived." You perceive init's boot time to be your/an issue. I haven't had such a problem.

---

You're coming off as dramatic and aggressively-emotional, which is my cue to walk away from our exchange.


You should not reboot that often anyway.


Users should be free to reboot as often as they want.

Parallelized init sequences have benefits, but I suspect this exaggerated '80 second' boot time, and the related '20 second' ideal, stems from either a misconfiguration, complete hogwash, or very particular worst-case setup (assuming an 8 core laptop has an SSD, and assuming a very conservative 200MB/s random-read speed, 80 seconds is enough time to populate 16GB of RAM from disk).


> Users should be free to reboot as often as they want.

Of course. But an init system should not be optimised for often reboots, since it's a marginal and unlikely scenario.


I just realized that I used a truism in a way that could be read as scolding -- not my intention and I apologize for my communication if I offended.

Starting up is a subset of rebooting, which is fine to spend time optimizing for, even though the Linux architecture lends itself towards long uptimes (well, until the complexity of systemd gets into the mix ;)).


http://0pointer.de/blog/projects/the-biggest-myths.html

systemd myth #2: systemd is about speed


And yet, on that link, point #3 tries to sell fast boot-up times for servers. It's about the level of marketing-doublespeak I'd expect from a RedHat-backed initiative.

I'm aware of their propaganda.


Doublespeak?

You said:

> it's working on "perceived" issues with Linux, e.g. plaintext logs being too large or sequential boot processing being too slow.

So you are claiming that the point of systemd is faster boot times.

I attempt to point out that this is false. As the myths page states:

> Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. [...] reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.

This comes up a lot because one of the most visible changes when distributions first switched to systemd was how fast it booted, which led to a lot of people talking about how fast systemd was.. which leads to a lot of people thinking that the speed was the whole point...

The usual response to this from people such as yourself is "who cares, boot times are irrelevant for servers anyway" which is why the next myth points out a couple of reasons why you might care about boot times on a server anyway.


I later thought about how I was making a logical fallacy in connecting the linked blog's assertions of "it's not about speed. speed matters for init on servers", apologies. The doublespeak quip was because the blog you linked-to sets arguments like "monolith? hardly! it's 69 individual binaries! complexity? oh, that's relative. systemd isn't compatible? systemd is plenty compatible as long as you do things our way."

>So you are claiming that the point of systemd is faster boot times.

I was stating that was one of their intentions, which I'm still not convinced wasn't one of their goals (that same blog even suggests that is one of the major advantages (reasons for existence?) http://0pointer.de/blog/projects/systemd.html).

If it's not a symptom of NIH or wanting speed-ups for init, I really don't understand its purpose. If they (systemd/redhat crew) wanted to write a better babysitter, write a faster "better" ("invented there") supervisord. If they want faster startup times, patch init to support N-routes and some hot-path shell scripts with C-based alternatives.

Disclaimer: I do see systemd as an overly complex, desktop-focused (e.g. if it works for GNOME and benefits laptop-users, out it goes), bloated, opaque (binary logs, pretending switches on a binary == having a toolchain) piece of RedHat-funded feature-creep that will be inferior, less stable than any init solution that follows a Unix philosophy. And one that, due to RedHat keeping a number of important players on the payroll, will end up boxing out decisions that would prevent it from being an underlying dependency.

Maybe I don't get it, but I really think I see it for what it is. I know I'm talking a lot of garbage, but I'm quite serious: if I'm foaming at the mouth like I just saw lizard people setting global policy in a secret meeting, please drop some knowledge on me.


Daemons being killed on user logout isn't a bad behavior, it's the documented and expected result.

It seems that the problem is that some apps need a feature/toggle that would kill them on logout, but the daemon call doesn't allow that - so a reasonable fix is to make such behavior possible (i.e., new api call), and change those apps who need new behavior instead of changing those apps who rely on this behavior staying as implemented, documented and intended originally.


If I can't do "nohup foo && logout" to go home and run foo over the weekend, systemd has a serious bug, because that has been the documented and expected way to do that ever since I started using Unix.


I believe the argument base is on the approach being used. Linux has a certain design principles it's built on; and it seems most of the objections are towards the SystemD's team completely disregarding said design principles.


Process persistence is not an issue, it's a feature.

"Desktop" users with their silly "issues" should go somewhere else and leave Unix alone.


"Desktop" users with their silly "issues" should go somewhere else and live Unix alone.

Were you unintentionally playing a parody of a traditionalist here?

I can't really say I have much of an opinion on systemd, aside from using it on newer systems and discovering that it hasn't really affected much. But it does seem that there's an unnecessary amount of antipathy between views on this issue, to the point where any discussion about it is difficult to extract any value from due to the noise. This comment kind of sums that up - issues of desktop users are important for desktop users of UNIX, and dismissing that seems a little irrational.


It's an environmental concern. An oil spill causes harm to the ecosystem, and if the response to it isn't correct, the damage can spread or future parties won't be particularly careful.


I'm not really sure I get your analogy. Oil spills are bad, so we should shout about how awful it is to have an economy dependent on it?


Sorry, probably not the most fitting analogy. And I think I might have attached my reply to the wrong parent comment.

What I was trying to express was that if tmux had changed itself to accommodate systemd, this would have negatively affected the Linux "environment" by making it more acceptable for breaking changes in underpinnings to occur. By future parties not being particularly careful, I meant that this could easily lead to "screen, tmux, and pulseaudio agreed to run as a systemd delegate, and we already wrote the code expecting that you would, so we see this as your bug, not ours." This is particularly concerning as a behavior because RedHat has the money to buy its way.


Do we even need those low quality, low value "desktop" users? Why should everyone else suffer in order to make things tiny bit easier for an average Joe?

Systemd is ill-designed throughout, and all of its design decisions do not have any place in Unix world. They're solving the silly desktop "issues" (note the quotes again - I do not believe any of this is a genuine issue at all) always in the most retarded and convoluted way possible.


I think you're maybe overreacting. It's worth considering that far from being targeted only at desktops, systemd seems to be pretty useful in server installs – the CoreOS ecosystem is a good example of where it works well.

I do get the impression that systemd isn't particularly well-designed, in that it feels like it would be equally possible to implement a more modular solution with better-defined and -designed APIs, such that the problems it solves could be handled collaboratively across the whole UNIX platform. I get the impression that this would make many people happier.

I do reject your characterisation problems as 'silly desktop issues' however – and it's shallow arguments like that, rather than genuine objections to the implementation of systemd that make the discussion so unconstructive.


Gnome not cleaning up after itself is a silly issue indeed. And especially not worthy of modifying a 40 years old policy, with suggestions like this making it even more silly and more non-issue.

A far more reasonable remedy to such a problem would have been to stop using Gnome, KDE and all the similar crap once and for all.


They claim it is about security but as much as I try to think of a scenario where this would affect a cracker, I can't. It will only affect legitimate users, thus systemd is essentially DRM now.

Another issue with tmux, is that maybe you want to have your ssh-agent available in it. To do that in a user friendly way, you have to start the ssh-agent first, then start tmux from a shell where you've exported its variables. Good luck with this now...

Very dissapointed with RedHat.


That's just insulting, it's making me want to remove systemd and use something else. As this statement might express: I'm not a systemd power-user, I just want my stuff to run as I'd expect it.


It seems that every systemd-related discussion is bound to be filled with all kinds of arguments, but completely devoid of discussion about the actual problem being solved. I can see how the "take no prisioners" attitude from systemd developers encourages this, but it doesn't lead anywhere.

In this case, the management of user processes is a real problem. 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.

When you run "screen" or "tmux" you expect them to survive a broken session (i.e. you expect them to behave like an independent session). However, when you run something under "nohup" you mostly expect it to survive the controlling terminal going away (a particular screen window or SSH connection being killed). You may be okay with it being killed if you no longer have a session to the server. A user process running in the background without a controlling terminal isn't a service, and from my experience most users don't expect it to be. There is a subtle difference between a "session" and a "connection" that's not properly implemented without systemd (and can be argued not to be properly implemented _with_ systemd).

The thing is how to implement this without "screen" or "tmux" explicitly informing systemd that they want a new session. Touching any API that's used beyond terminal multiplexers defeats the whole purpose.


It seems clear that the systemd devs are not playing well with others, though perhaps I am wrong about that ...

Why make such a change instead of just making it optional? What would be the impact in such a case?

Did they announce it well in advance and document this?

If not, then the question that springs to mind is "I don't want these guys in charge of helping me administer my systems."

Imagine updating via apt or yum, and having a bunch of important processes killed with no warning when you log out for the day.


So programs that have no problems whatsoever (like tmux and screen) will have to add linux-specific code to support a systemd feature no one asked for.

Nice. (/s)


Not just Linux specific, systemd specific.


I am sure systemd will just write a replacement for tmux in the long run. After all they know what's good for everyone.


In theory, the systemd developers could resurrect systemd-consoled as a tmux replacement. It already had a DEC VT style terminal emulator, knowledge of these systemd abstractions, and Desktop Bus capability.

But as pointed out already on this page, that would be to miss the wood for the trees. There are many programs that are hit by the fact that they call daemon() with the idea of escaping being killed at the end of the login session and yet are still (now, as of systemd version 230) killed by systemd at (final) logout. The systemd developers themselves mentioned screen and tmux. But others have already mentioned mosh-server and deluged (ironically in the bug report that supposedly drove this systemd change). It will almost certainly affect things like emacs --daemon as well. The list grows on and on.

* http://askubuntu.com/questions/338135/

* http://blog.refu.co/?p=1296#comment-61675

Should the systemd developers fork emacs so that they have a logind-aware version of emacs --daemon?


This isn't really systemd's fault. It just happens to have an intrusive solution. Even the solution of using daemon(3) is incorrect (despite having existed for 30+ years).

A user_daemon() interface is the Right Way. Processes should not survive past the user session without some fancy footwork, not as a default matter of course. Applications will have to be reworked in some cases, but that's because linux has been subject to bad userspace practices all over the place for decades and after the big issues of drivers have been hashed out, time for a little objectivity in handling processes.


Wouldn't this mean that on distributions with binary packages, they'd either have to give tmux a dependency on systemd or they'd have to make a separate, systemd-less tmux package?


It might depend on libdbus, but it wouldn't require systemd to be installed and running


What about systems that don't have or need libdubs. Tmux does not depend on dbus.


I't just a suggestion, if not - tmux users will have issue with systemd services. Not a big deal. I think linux community just loves to overreact everything related to the systemd.


My architectural critique is becoming more pertinent (although they've had the sense to since deprecate the useless snapshot units): http://blog.darknedgy.net/technology/2015/10/11/0/

Either way, dissent is futile. Jump to a niche distro or ditch GNU/Linux entirely if systemd bothers you.


Would be bikeshedding, but...

I think there is some good intent in systemd's change. But they should have approached tmux/screen/community before making the change and a release which broke things. They should have asked for feedback and such and see if tmux is willing to do what they propose. Simply hammering over things as if you hold powers over other's codebases doesn't come off as very positive.

But oh well...


Some of the other comments in this thread indicate that tmux not confirming to the specification is a known issue that people have been trying to get fixed for a few years. I'm not knowledgeable enough to know how correct this is, but it appears that it's not an entirely one-sided argument.


Or at least a kind "hey, we are releasing this new crap, your software will stop working in 2 weeks".


Playing around with freebsd as the clown operation called systemd continues to unfold.


Looks like stepping away from Unix philosophy of tools with clear boundaries.


what about tmux users on systemd free machines? Do they expect, that everyone have to run systemd now?


Worst is that since systemd you have less choices. I've been doing my personal research and while you have a dozen of interesting projects for the desktop there is not that much options for the server specially if your production environment is cloud based.


Just a note. Slackware is going to do its next release (14.2) some time soon.

It's nice, no drama, things are where you expect them to be.


So what? Is this that different from, for example, inhibiting a screen saver during video playback?


It's fascinating to see the Github emoji responses.


Systemd is destroying Linux. I switched to FreeBSD.


once again we see a comment like: "at this point it might be better stopping people (you know, users) commenting on this in how it affects their day-to-day use of the software"

Am I alone in thinking such comments are ostensibly helpful but in fact passive aggressive, because they stifle the user community's only relevant channel of complaint?


fly-tipping in userspace


It is a useful feature, and it was already there prior to this version. It could be turned on before, and looking at it, Arch and Debian are going to ignore upstream here (which is unusual for ARch, showing how dumb they think this is) and keep it off by default.

All that happened in v230 is that a default of off was flipped to on, nothing more.

What people criticize is that a default was change breaking behaviour and biting people who don't expect it. The feature is useful for system administrators who want it of course


Am I the only person who likes the idea of being able to logout and log back in again and have all my processes still running and arranged the way I had them? Maybe we just need a "hard logout" option for people who want everything killed.

Usually log outs are already instant so I'm not sure what problem this fixes.


If you want your processes to be running the way it is, then just lock your screen or switch user instead of log out. A log out, in my opinion is like a shutdown of the user session. So all user processes should stop running.


So I should loose my state when I disconnect from my SSH session because my train went through a tunnel? This attitude might make sense on a desktop GUI machine, but in the real world far more developers use Linux remotely over SSH, which is where tmux really shines. I use it to leave my "IDE" (vim and friends) running on my server, so I can resume work remotely from any computer.


That post is confusing problem with solution. When you lose your ssh connection you are not logging out on purpose. Even ssh can help you there, though. You can configure ssh clients (and also servers I believe) to survive a session to be gone for minutes, even hours if you desire.

So your problem is that you haven't spent enough time learning to configure your ssh according to your needs. The cool thing is that ssh configs can be done for a specific session (if it happens just once in a while or you experiment about the right configuration), it can be done per target (in case you want to react differently on your personal blog and your company development host), and globally (to apply always). Have fun reading. You may find that ssh can solve a lot of problems and in some people's mind even solves problems like other tools but more elegant (I personally prefer it over http-proxys and VPNs as well).


No. I often purposefully log out of an SSH session and expect to come back later and have my tmux session still the same. Sometimes I log out of my desktop at home that I'm physically at, get to someplace else, log in via SSH, and reconnect to the same tmux session I had running when I was at home. This is one of the primary features of tmux. It's not about misconfigured SSH sessions.


Yes you are right. In that case you have tmux to keep your session. If it doesn't do it, it's pretty much tmux's fault. I understood the previous message as if losing the connection on a train ride would be the main issue.


How is it tmux's fault when it is systemd that is killing processes? Tmux uses the standard mechanism to inform the system that it should live on, systemd no longer respects that mechanism.


And you can continue doing that with systemd – systemd just requires either tmux or you to mark the process specifically as long running, as, by default, processes will be killed during logout.

Making it explicit means you have more control about what will continue to run.


That functionality has already existed through the way that tmux already does it, via setsid() and daemon(). Systemd killing everything willy-nilly is a bug.


The right tool for your scenario is mosh.

https://mosh.mit.edu/


And the right tool for persistent terminal sessions that span SSH, physical access, VNC, and etc. was tmux until systemd broke it in order to poorly address a problem that primarily affects one DE (GNOME).


This is an argument about tmux (and anciliarily screen) which are built to allow the exact opposite. If you need to run a task that will take a day to run you could NOHUP and background it before logging out for the day, or you launch screen and have it run continuously in the "background" interactively.

I wonder if this breaks mosh as well, if it's anything with per-user persistence.



The processes the user wants to stop should stop and the ones they want to keep running should keep running. There is enough demand for this capability that there are multiple ways to do it, from disown in the shell, to cron/at, to screen/tmux/emacs and probably more besides.


Yes, and the answer for that is systemd-run.

Systemd’s change is just "processes have to explicitly declare they are long-running, or they’ll be killed".

How else would you do it?


It likely already does "the right thing" according to POSIX. tmux starts a server and then immediately connects to it a client. The server portion is what's being erroneously killed. Starting a server is a relatively normal thing, and one of the steps is to create a new session. setsid() is how you do that. Systemd shouldn't kill processes in a separate session.


By using the unix tools that have existed since forever and a day. Detatching from the user's session. If a program is broken and doesn't die when it's supposed to, fix the program, not every other program that behaves correctly with functionality that's been around for decades.


And that’s exactly the opposite of how you build efficient and secure systems.

This is basically sandboxing time itself.

The bad software will never be fixed. Never. But you can put it in a jail, and let the user configure that good software won’t have that jail.


The bad software will update itself to continue being bad using the new mechanisms that systemd provides to allow it to be bad. By spending efforts to fix the bad software, or to write better software, you will do much greater things than to break the multitude of software that behaves correctly.



What if you're on shared system like a school computer and you want to be able to log into the same session in different classrooms?

Most systems have a single human user anyway and there is no need for them to log out. For systems that have multiple users it seems more convenient to be able to pick up where you left off.


> Maybe we just need a "hard logout" option for people who want everything killed.

Maybe we need a way for people to lock their screens without traditionally logging out... wondered the person who implemented the functionality 40 years ago.


It has been some time since I used linux, but in Windows, for your first question you just close the lid on your notebook or lock the screen(suspend), and for the "hard logout", you just logout, I thought Ubuntu used to work like this. PS: english is not my first language.


I a unrelated story tmux developers ask systemd developers if systemd can "make me a sandwich" .




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

Search: