4 ms·

Ouch, what on earth does "log out" even mean? What a terrible way to run any computer other than maybe a single user laptop.

kaba0 5y ago
Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.
- tyingq 5y ago
  It wasn't respecting things that have been considered normal for a while. Even calling setsid(), which tmux does, didn't save it from being killed. Same for nohup. When the systemd people say session, they mean you would have to specifically do some kind of dbus call I'm not familiar with.
- e12e 5y ago
  > They can easily register a user service and continue running there. Typically this was an issue on B) workstations, and B) servers, where you might log in as a regular user without super user access. And this[1] (might?) now work as advertised in the documentation - but the discussion around the bug doesn't induce great confidence... https://github.com/systemd/systemd/issues/3388 https://github.com/systemd/systemd/issues/3388 [1] example no 5 here: https://www.man7.org/linux/man-pages/man1/systemd-run.1.html#EXAMPLES https://www.man7.org/linux/man-pages/man1/systemd-run.1.html...
- josephcsible 5y ago
  Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead". > They can easily register a user service and continue running there. So systemd came in and broke the 50-year-old way of doing things, and now the programs that got broken should all have to add systemd-specific code to work again?
  - kaba0 5y ago
    > Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? Yes. Just because it is 50-years-old doesn’t make it suddenly a valid approach. There are 4 states here - process running with usual semantics for closing, process running that would like to linger in the background, and the frozen version of this two. How should a service manager/resource handle — that is very much in-scope for systemd differentiate between a frozen process that should very much be cleaned up in the no-linger case, and any process wanting to linger? And there are well-established ways to determine whether a process is frozen — pinging it expecting a specific answer. Systemd differentiates between no-linger/linger by introducing user services - one should only write a trivial alias/wrapper script for tmux and can continue to use it to their liking. Also, it has a compile time flag, as well as a runtime config one - it is up to the distro or the user to revert back to the old way.
    - tyingq 5y ago
      Is setsid() also a hack?
    - josephcsible 5y ago
      What ways are there to tell if a process is frozen that only work if it registers a systemd user service?

kaba0 5y ago

Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.

tyingq 5y ago
It wasn't respecting things that have been considered normal for a while. Even calling setsid(), which tmux does, didn't save it from being killed. Same for nohup. When the systemd people say session, they mean you would have to specifically do some kind of dbus call I'm not familiar with.
e12e 5y ago
> They can easily register a user service and continue running there. Typically this was an issue on B) workstations, and B) servers, where you might log in as a regular user without super user access. And this[1] (might?) now work as advertised in the documentation - but the discussion around the bug doesn't induce great confidence... https://github.com/systemd/systemd/issues/3388 https://github.com/systemd/systemd/issues/3388 [1] example no 5 here: https://www.man7.org/linux/man-pages/man1/systemd-run.1.html#EXAMPLES https://www.man7.org/linux/man-pages/man1/systemd-run.1.html...
josephcsible 5y ago
Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead". > They can easily register a user service and continue running there. So systemd came in and broke the 50-year-old way of doing things, and now the programs that got broken should all have to add systemd-specific code to work again?
- kaba0 5y ago
  > Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? Yes. Just because it is 50-years-old doesn’t make it suddenly a valid approach. There are 4 states here - process running with usual semantics for closing, process running that would like to linger in the background, and the frozen version of this two. How should a service manager/resource handle — that is very much in-scope for systemd differentiate between a frozen process that should very much be cleaned up in the no-linger case, and any process wanting to linger? And there are well-established ways to determine whether a process is frozen — pinging it expecting a specific answer. Systemd differentiates between no-linger/linger by introducing user services - one should only write a trivial alias/wrapper script for tmux and can continue to use it to their liking. Also, it has a compile time flag, as well as a runtime config one - it is up to the distro or the user to revert back to the old way.
  - tyingq 5y ago
    Is setsid() also a hack?
  - josephcsible 5y ago
    What ways are there to tell if a process is frozen that only work if it registers a systemd user service?