7 ms·

nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be awa

nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.

plaguepilled 4y ago
Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.
- erik_seaberg 4y ago
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nohup.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
  - teddyh 4y ago
    Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
    - erik_seaberg 4y ago
      I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
      - kaba0 4y ago
        How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.
        erik_seaberg 4y ago
        init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
        effie 4y ago
        systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.
      - teddyh 4y ago
        systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.
        erik_seaberg 4y ago
        When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it? Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
    - WastingMyTime89 4y ago
      > The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session. That was proposed to nohup when systemd introduced the modification. It’s what nohup does on macOS. A very productive discussion was happening but then the anti-systemd mob showed up with pitchforks, brigaded the discussion on the bug tracker and made sure nothing good would come out of it. That’s when I personally decided Linux was a lost cause and definitely switched to macOS.
      - effie 4y ago
        > I personally decided Linux was a lost cause and definitely switched to macOS. That is an strange course of action. So because you saw some low quality discussion on the internet, you switched from free software you can influence to commercial one you can't?
        WastingMyTime89 4y ago
        I don’t care about having this kind of influence. These are tools. I want the tools I use to be good so I buy good tools. It’s not about low quality discussion. A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
        effie 4y ago
        > I want the tools I use to be good so I buy good tools Right, good strategy. > A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices. Do you mean toxic users influence some developers to make bad decisions? Any examples? Toxic users dumping on systemd may be one, but I don't think they have that much impact, systemd seems pretty successful in not giving away. Anyway systemd is a very specific case, this is not representative of all linux software projects.
  - xdfgh1112 4y ago
    They broke tmux too: https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions https://superuser.com/questions/1372963/how-do-i-keep-system... Systemd does a lot of good but they like to move fast and break things. Making tmpdir per process, their homedir changes etc are all good for security but tend to break things in unexpected ways
    - dinosaurdynasty 4y ago
      They've never done tmpdir per process... There's a PrivateTmp option for services, but that has to be enabled explicitly
      - xdfgh1112 4y ago
        It is enabled by default on some distros.
  - lrvick 4y ago
    Today you still have this functionality as an unprivileged user via systemd --user units in .config. Unlike nohup you get proper logging and processes can even restart automatically on reboot if you want.
kaba0 4y ago
Nohup is a disgusting hack from a previous century. I don’t see how having less information on what is happening to a process good — nohup interprets supposedly meaningful signals never meant for this misuse differently. If you want to continue to run a process you have to start a service which is exactly that.
- Nursie 4y ago
  No, I don't have to do that at all, I can in fact use the standard unix way of making a process not terminate on SIGHUP by telling it to ignore SIGHUP. SIGHUP is not a signal to shut down, it's a signal that says the controlling terminal is gone. The action taken by the process at that point is the decision of the process and the user that launched it, not the init system. This is exactly what it is for. Changing that without understanding what people used it for across UNIX vendors for decades, was dumb. And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag. It's not just random long-running batch jobs it killed either, it seems that it would kill all sorts of useful stuff people run for reliability. The irony of the init system killing screen/tmux sessions which people run specifically to keep their shell going in case of a disconnect!
  - kaba0 4y ago
    >And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag. Why do you assume they didn't know about this quite basic mechanism? They added 2 configuration options, one at compile time (to set the default) and another configurable by the user. In fact, distro maintainers didn't look up what it did and they just compiled it as is, resulting in the surprising behavior of killing lingering processes. Also, it is an init and service management system and long-running processes are services. If you want to run something for "reliability" you should create a service for it, or just run the command with "systemd-run", to properly communicate with the responsible process manager what it supposed to do when the user logs out (and to actually make it reliable, e.g. you can then set it to auto-restart on failure, etc) Safely killing lingering processes and cleaning up after them is the correct default behavior, so systemd just tries to enforce that - they actually communicated with nohup maintainers to optionally add this systemd communication, so that "nohup whatever" would still work, but they were not open to it.

nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.

plaguepilled 4y ago

Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.

erik_seaberg 4y ago
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nohup.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
- teddyh 4y ago
  Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
  - erik_seaberg 4y ago
    I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
    - kaba0 4y ago
      How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.
      - erik_seaberg 4y ago
        init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
      - effie 4y ago
        systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.
    - teddyh 4y ago
      systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.
      - erik_seaberg 4y ago
        When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it? Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
  - WastingMyTime89 4y ago
    > The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session. That was proposed to nohup when systemd introduced the modification. It’s what nohup does on macOS. A very productive discussion was happening but then the anti-systemd mob showed up with pitchforks, brigaded the discussion on the bug tracker and made sure nothing good would come out of it. That’s when I personally decided Linux was a lost cause and definitely switched to macOS.
    - effie 4y ago
      > I personally decided Linux was a lost cause and definitely switched to macOS. That is an strange course of action. So because you saw some low quality discussion on the internet, you switched from free software you can influence to commercial one you can't?
      - WastingMyTime89 4y ago
        I don’t care about having this kind of influence. These are tools. I want the tools I use to be good so I buy good tools. It’s not about low quality discussion. A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
        effie 4y ago
        > I want the tools I use to be good so I buy good tools Right, good strategy. > A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices. Do you mean toxic users influence some developers to make bad decisions? Any examples? Toxic users dumping on systemd may be one, but I don't think they have that much impact, systemd seems pretty successful in not giving away. Anyway systemd is a very specific case, this is not representative of all linux software projects.
- xdfgh1112 4y ago
  They broke tmux too: https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions https://superuser.com/questions/1372963/how-do-i-keep-system... Systemd does a lot of good but they like to move fast and break things. Making tmpdir per process, their homedir changes etc are all good for security but tend to break things in unexpected ways
  - dinosaurdynasty 4y ago
    They've never done tmpdir per process... There's a PrivateTmp option for services, but that has to be enabled explicitly
    - xdfgh1112 4y ago
      It is enabled by default on some distros.
- lrvick 4y ago
  Today you still have this functionality as an unprivileged user via systemd --user units in .config. Unlike nohup you get proper logging and processes can even restart automatically on reboot if you want.

kaba0 4y ago

Nohup is a disgusting hack from a previous century. I don’t see how having less information on what is happening to a process good — nohup interprets supposedly meaningful signals never meant for this misuse differently. If you want to continue to run a process you have to start a service which is exactly that.

Nursie 4y ago
No, I don't have to do that at all, I can in fact use the standard unix way of making a process not terminate on SIGHUP by telling it to ignore SIGHUP. SIGHUP is not a signal to shut down, it's a signal that says the controlling terminal is gone. The action taken by the process at that point is the decision of the process and the user that launched it, not the init system. This is exactly what it is for. Changing that without understanding what people used it for across UNIX vendors for decades, was dumb. And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag. It's not just random long-running batch jobs it killed either, it seems that it would kill all sorts of useful stuff people run for reliability. The irony of the init system killing screen/tmux sessions which people run specifically to keep their shell going in case of a disconnect!
- kaba0 4y ago
  >And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag. Why do you assume they didn't know about this quite basic mechanism? They added 2 configuration options, one at compile time (to set the default) and another configurable by the user. In fact, distro maintainers didn't look up what it did and they just compiled it as is, resulting in the surprising behavior of killing lingering processes. Also, it is an init and service management system and long-running processes are services. If you want to run something for "reliability" you should create a service for it, or just run the command with "systemd-run", to properly communicate with the responsible process manager what it supposed to do when the user logs out (and to actually make it reliable, e.g. you can then set it to auto-restart on failure, etc) Safely killing lingering processes and cleaning up after them is the correct default behavior, so systemd just tries to enforce that - they actually communicated with nohup maintainers to optionally add this systemd communication, so that "nohup whatever" would still work, but they were not open to it.