6 ms·

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.

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.

sandGorgon 10y ago
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.
- msbarnett 10y ago
  > 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".
  - Tuna-Fish 10y ago
    > 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.
    - icebraining 10y ago
      But isn't this mechanism they're asking tmux to use a way to evade being reaped?
      - msbarnett 10y ago
        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.
    - thwarted 10y ago
      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.
- Sanddancer 10y ago
  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.
- detaro 10y ago
  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.
  - justinsaccount 10y ago
    > 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 http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux
    - tremon 10y ago
      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?
    - msbarnett 10y ago
      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.
- raverbashing 10y ago
  > 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
lbenes 10y ago
> 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.
- msbarnett 10y ago
  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.
  - the_why_of_y 10y ago
    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.

sandGorgon 10y ago

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.

msbarnett 10y ago
> 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".
- Tuna-Fish 10y ago
  > 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.
  - icebraining 10y ago
    But isn't this mechanism they're asking tmux to use a way to evade being reaped?
    - msbarnett 10y ago
      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.
  - thwarted 10y ago
    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.
Sanddancer 10y ago
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.
detaro 10y ago
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.
- justinsaccount 10y ago
  > 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 http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux
  - tremon 10y ago
    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?
  - msbarnett 10y ago
    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.
raverbashing 10y ago
> 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

lbenes 10y ago

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

msbarnett 10y ago
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.
- the_why_of_y 10y ago
  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.