5 ms·

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 automatical

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

raverbashing 10y ago
> 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
- busterarm 10y ago
  the libsystemd dependency is the goal systemd is trying to achieve though, in every package.
  - okket 10y ago
    [stupid discussion. deleted]
    - busterarm 10y ago
      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.
- sandGorgon 10y ago
  Yes it's breaking historic behavior - but it's taking care to bring in better behavior by trying to . maintain backward compatibility.
  - Sanddancer 10y ago
    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.
feld 10y ago
It's doing something very wrong. They are using this as a sledgehammer to solve a gnome issue.
deleted 10y ago
[deleted]
sklogic 10y ago
> 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?
JdeBP 10y ago
> 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 https://news.ycombinator.com/item?id=11782364 who are expecting nohup to effect exactly that, with reference to the Single Unix Specification no less.
icebraining 10y ago
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)
- justabystander 10y ago
  > 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 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.
  - icebraining 10y ago
    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.

raverbashing 10y ago

> 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

busterarm 10y ago
the libsystemd dependency is the goal systemd is trying to achieve though, in every package.
- okket 10y ago
  [stupid discussion. deleted]
  - busterarm 10y ago
    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.
sandGorgon 10y ago
Yes it's breaking historic behavior - but it's taking care to bring in better behavior by trying to . maintain backward compatibility.
- Sanddancer 10y ago
  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.

feld 10y ago

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

deleted 10y ago

[deleted]

sklogic 10y ago

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

JdeBP 10y ago

> 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 https://news.ycombinator.com/item?id=11782364 who are expecting nohup to effect exactly that, with reference to the Single Unix Specification no less.

icebraining 10y ago

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)

justabystander 10y ago
> 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 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.
- icebraining 10y ago
  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.