4 ms·

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 hack

by 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.
- justinsaccount 10y ago
  > 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 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.
  - JdeBP 10y ago
    ... 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=11798173 * https://news.ycombinator.com/item?id=11798328 https://news.ycombinator.com/item?id=11798328
    - justinsaccount 10y ago
      Tomorrows systemd hate post: Systemd developer asks libc to add systemd specific code
      - JdeBP 10y ago
        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.
        justinsaccount 10y ago
aidenn0 10y ago
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()!

by gcb0 10y ago

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.

justinsaccount 10y ago
> 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 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.
- JdeBP 10y ago
  ... 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=11798173 * https://news.ycombinator.com/item?id=11798328 https://news.ycombinator.com/item?id=11798328
  - justinsaccount 10y ago
    Tomorrows systemd hate post: Systemd developer asks libc to add systemd specific code
    - JdeBP 10y ago
      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.
      - justinsaccount 10y ago

aidenn0 10y ago

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()!