6 ms·

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 lo

by gpvos 10y ago

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

IshKebab 10y ago
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.
- gaius 10y ago
  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.
  - Twirrim 10y ago
    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.
    - MertsA 10y ago
      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.
      - thwarted 10y ago
        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.
        dsr_ 10y ago
        Less intrusive and play better with other systems, because they don't believe that they are The Way, The Truth and The Life.
        thwarted 10y ago
        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!".
        emp_zealoth 10y ago
        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
    - vertex-four 10y ago
      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.
- gcb0 10y ago
  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.
  - raverbashing 10y ago
    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)
    - LnxPrgr3 10y ago
      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.
    - ASalazarMX 10y ago
      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.
  - danudey 10y ago
    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.
- danudey 10y ago
  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.
  - anonymousab 10y ago
    SIP seemed like an overture in that direction.
  - jfoks 10y ago
    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.
- tremon 10y ago
  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.
  - thwarted 10y ago
    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.
digi_owl 10y ago
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.

by gpvos 10y ago

IshKebab 10y ago

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.

gaius 10y ago
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.
- Twirrim 10y ago
  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.
  - MertsA 10y ago
    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.
    - thwarted 10y ago
      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.
      - dsr_ 10y ago
        Less intrusive and play better with other systems, because they don't believe that they are The Way, The Truth and The Life.
        thwarted 10y ago
        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!".
        emp_zealoth 10y ago
        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
  - vertex-four 10y ago
    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.
gcb0 10y ago
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.
- raverbashing 10y ago
  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)
  - LnxPrgr3 10y ago
    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.
  - ASalazarMX 10y ago
    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.
- danudey 10y ago
  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.
danudey 10y ago
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.
- anonymousab 10y ago
  SIP seemed like an overture in that direction.
- jfoks 10y ago
  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.
tremon 10y ago
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.
- thwarted 10y ago
  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.

digi_owl 10y ago

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.