6 ms·

> This violates the rule of least surprise. Maybe I'm completely misunderstanding things here, but when I log out, I expect all of my processes to be killed. W

> This violates the rule of least surprise. Maybe I'm completely misunderstanding things here, but when I log out, I expect all of my processes to be killed. When I'm logged off, and if another user logs on, it would be kind of weird if the system was still playing my music, etc, wouldn't it? If your processes don't die when you log off, then what exactly does it mean to "log off"? Or maybe the issue is that it's the init system doing this, rather than some other component?

Nursie 10y ago
No, if I background and nohup something, it ought to stay there until or unless I kill it or it exits. What it means to log off is to end the session you're in. A desktop session would end all the windows and systray-type stuff you're running, a terminal session would end the shell. but any processes you have explicitly daemonised or nohup'd should carry on. Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing?
- wallacoloo 10y ago
  > Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.
  - ams6110 10y ago
    nohup dates way back, most unix computers were not owned by a single person but were used by dozens if not hundreds of users. People had needs to run jobs (even compiles could take hours) that they would not want terminated if their dial-up connection dropped (common occurrence). Among other reasons.
    - kevin_nisbet 10y ago
      Agreed, at work we use nohup / screen for many important tasks. These tasks are items like doing an upgrade, or migration, or a long running script that you want to protect from a dropped ssh connection. Networks are unreliable, your local system may be unreliable, and the last thing we want to happen is for a script or program to die while making changes to the system that leave it in an inconsistent state. In my limited understanding, nohup was a very simple mechanism to achieve this. So to me, when you logoff or drop a connection, the system will send a HUP to all the processes in the tree belonging to that session. If the process doesn't accept the HUP, well then it doesn't want to die right now, which is what nohup allowed you to do by intercepting / wrapping the HUP. I assume screen worked on a similar principle and just ignores the HUP since it knows you may want to re-attach later. Now it sounds like they are working on or have another way to achieve the same result in SystemD, I'm just very curious what the thoughts or reasoning is that this should be a thing. Anyways, all I can say is that to me, changing this behaviour if I didn't see the release notes or this bug, would cause some very unexpected behaviour for me interacting with a SystemD system, where some of the basic mechanisms I use and encourage for change safety would no longer work. I suspect many others also use screen/nohup, and will be in for a big surprise.
  - digi_owl 10y ago
    Err unless i am totally off target, unix do not have anything like "system". The closest you will get is something running as the root user. And doing everything as root is bad juju, as we can see from the DOS legacy that plagues Windows to this day.
    - wallacoloo 10y ago
zik 10y ago
UNIX was designed to run background processes and do offline computing. I log into multiple remote systems every day and connect to my ongoing tmux sessions in other countries. This isn't exactly an unusual use case. Banning this is a big downgrade in functionality.
- wallacoloo 10y ago
  Yeah, I get this. I don't disagree that it shouldn't be possible to run persistent sessions. I think it's just an issue of me finding the terminology counterintuitive. > I log into multiple remote systems every day and connect to my ongoing tmux sessions in other countries. In this case, it sounds to me that you aren't logging out. It sounds like you're effectively just suspending the connection to your session and then coming back to it later. i.e. you didn't SSH in and then run 'exit' from within your sesson, right? Or is that indeed the way it's done?
  - comex 10y ago
    Depends what you mean by 'session'. Unix has long had a concept of sessions, where the login shell will send SIGHUP to everything in the session when it exits; daemons like tmux (the server side) indicate their intent to start a separate session using setsid(). Apparently systemd has its own concept of session which is the same idea but completely separate, and requires some systemd specific magic to split off. Yay!
    - JdeBP 10y ago
      In fairness, X desktops have their own concepts of sessions that are not congruent with kernel sessions, similarly. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/windows-nt-session.html#UnixLoginSession http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/wi... * https://www.x.org/releases/X11R7.6/doc/man/man1/xdm.1.xhtml#heading3 https://www.x.org/releases/X11R7.6/doc/man/man1/xdm.1.xhtml#...
  - wtallis 10y ago
    I'm not a tmux user, but what you describe is pretty much how it works for screen. You use a keyboard shortcut to detach from your screen session, then `exit` to terminate the login shell that ssh ran and close the ssh connection. Later, you can log back in through ssh or locally and run `screen -r` to resume the detached session.
cturner 10y ago
One of the primary use cases of tmux/screen is to act as a base for Process Groups so that this does not happen. There was a case for the init system doing this when unix was young. But changing it now breaks convention, and compat with other distros, without good cause. Let me explain where I come from. At times I write distributed systems that expect to be based in a non-specific unix. Whenever I mess around in an area such as process control, I carefully read the relevant section of Stevens and my distro's own docs (usually linux and until now I have tried to avoid caring about choice in init system). And - in these phases - I write in C because I don't trust that runtimes like python won't have wacky defaults that make the system hard to reason about. This issue is a groaner, because it suggests that mainstream linux is becoming harder to reason about during development and debugging. Instead of being able to think clearly and tell the computer what to do, you will be constantly looking over your shoulder for unnecessary vagueries of your local systemd configuration and whatever quirks have been introduced by the neckbeard who owns commit rights to its default behaviours. This bug and the abrasive german's response in the ticket suggest to me that there is a point in the near future where people who care about developing against the unix api will Bozo-bit systemd-affected distros altogether. Which would be a shame for all the good citizens who have steadily done low ego work towards those distros.
- AnonymousPlanet 10y ago
  In an earlier version of your post you said > This reminds me of a character of windows-based development that I find exhausting: opaque layers of unnecessary complexity. This is pretty much exactly how I feel about this whole thing. While designing NT, MS made a number of assumptions and decisions that were sensible from an engineering point of view back then. Especially if you're very much into OO (wich was the new rage back then). But from an administrator or system programmer point of view, these byzantine structures get more in the way than they help. On top of that, it makes integrating new ideas harder and you end up with layers and layers of API sediment. The people behind systemd are making very similar decisions and assumptions, deviating from the very principles of Unix that prevent this short sightedness.
  - cturner 10y ago

Nursie 10y ago

No, if I background and nohup something, it ought to stay there until or unless I kill it or it exits. What it means to log off is to end the session you're in. A desktop session would end all the windows and systray-type stuff you're running, a terminal session would end the shell. but any processes you have explicitly daemonised or nohup'd should carry on. Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing?

wallacoloo 10y ago
> Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.
- ams6110 10y ago
  nohup dates way back, most unix computers were not owned by a single person but were used by dozens if not hundreds of users. People had needs to run jobs (even compiles could take hours) that they would not want terminated if their dial-up connection dropped (common occurrence). Among other reasons.
  - kevin_nisbet 10y ago
    Agreed, at work we use nohup / screen for many important tasks. These tasks are items like doing an upgrade, or migration, or a long running script that you want to protect from a dropped ssh connection. Networks are unreliable, your local system may be unreliable, and the last thing we want to happen is for a script or program to die while making changes to the system that leave it in an inconsistent state. In my limited understanding, nohup was a very simple mechanism to achieve this. So to me, when you logoff or drop a connection, the system will send a HUP to all the processes in the tree belonging to that session. If the process doesn't accept the HUP, well then it doesn't want to die right now, which is what nohup allowed you to do by intercepting / wrapping the HUP. I assume screen worked on a similar principle and just ignores the HUP since it knows you may want to re-attach later. Now it sounds like they are working on or have another way to achieve the same result in SystemD, I'm just very curious what the thoughts or reasoning is that this should be a thing. Anyways, all I can say is that to me, changing this behaviour if I didn't see the release notes or this bug, would cause some very unexpected behaviour for me interacting with a SystemD system, where some of the basic mechanisms I use and encourage for change safety would no longer work. I suspect many others also use screen/nohup, and will be in for a big surprise.
- digi_owl 10y ago
  Err unless i am totally off target, unix do not have anything like "system". The closest you will get is something running as the root user. And doing everything as root is bad juju, as we can see from the DOS legacy that plagues Windows to this day.
  - wallacoloo 10y ago

zik 10y ago

UNIX was designed to run background processes and do offline computing. I log into multiple remote systems every day and connect to my ongoing tmux sessions in other countries. This isn't exactly an unusual use case. Banning this is a big downgrade in functionality.

wallacoloo 10y ago
Yeah, I get this. I don't disagree that it shouldn't be possible to run persistent sessions. I think it's just an issue of me finding the terminology counterintuitive. > I log into multiple remote systems every day and connect to my ongoing tmux sessions in other countries. In this case, it sounds to me that you aren't logging out. It sounds like you're effectively just suspending the connection to your session and then coming back to it later. i.e. you didn't SSH in and then run 'exit' from within your sesson, right? Or is that indeed the way it's done?
- comex 10y ago
  Depends what you mean by 'session'. Unix has long had a concept of sessions, where the login shell will send SIGHUP to everything in the session when it exits; daemons like tmux (the server side) indicate their intent to start a separate session using setsid(). Apparently systemd has its own concept of session which is the same idea but completely separate, and requires some systemd specific magic to split off. Yay!
  - JdeBP 10y ago
    In fairness, X desktops have their own concepts of sessions that are not congruent with kernel sessions, similarly. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/windows-nt-session.html#UnixLoginSession http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/wi... * https://www.x.org/releases/X11R7.6/doc/man/man1/xdm.1.xhtml#heading3 https://www.x.org/releases/X11R7.6/doc/man/man1/xdm.1.xhtml#...
- wtallis 10y ago
  I'm not a tmux user, but what you describe is pretty much how it works for screen. You use a keyboard shortcut to detach from your screen session, then `exit` to terminate the login shell that ssh ran and close the ssh connection. Later, you can log back in through ssh or locally and run `screen -r` to resume the detached session.

cturner 10y ago

One of the primary use cases of tmux/screen is to act as a base for Process Groups so that this does not happen. There was a case for the init system doing this when unix was young. But changing it now breaks convention, and compat with other distros, without good cause. Let me explain where I come from. At times I write distributed systems that expect to be based in a non-specific unix. Whenever I mess around in an area such as process control, I carefully read the relevant section of Stevens and my distro's own docs (usually linux and until now I have tried to avoid caring about choice in init system). And - in these phases - I write in C because I don't trust that runtimes like python won't have wacky defaults that make the system hard to reason about. This issue is a groaner, because it suggests that mainstream linux is becoming harder to reason about during development and debugging. Instead of being able to think clearly and tell the computer what to do, you will be constantly looking over your shoulder for unnecessary vagueries of your local systemd configuration and whatever quirks have been introduced by the neckbeard who owns commit rights to its default behaviours. This bug and the abrasive german's response in the ticket suggest to me that there is a point in the near future where people who care about developing against the unix api will Bozo-bit systemd-affected distros altogether. Which would be a shame for all the good citizens who have steadily done low ego work towards those distros.

AnonymousPlanet 10y ago
In an earlier version of your post you said > This reminds me of a character of windows-based development that I find exhausting: opaque layers of unnecessary complexity. This is pretty much exactly how I feel about this whole thing. While designing NT, MS made a number of assumptions and decisions that were sensible from an engineering point of view back then. Especially if you're very much into OO (wich was the new rage back then). But from an administrator or system programmer point of view, these byzantine structures get more in the way than they help. On top of that, it makes integrating new ideas harder and you end up with layers and layers of API sediment. The people behind systemd are making very similar decisions and assumptions, deviating from the very principles of Unix that prevent this short sightedness.
- cturner 10y ago