4 ms·

> If you really need to run longer, tell it to the system. ... with nohup. Which now doesn't work. * https://news.ycombinator.com/item?id=11782364 https://ne

• protomyth 10y ago
  How did they justify breaking nohup? I thought it was a common usage pattern to nohup long running jobs before logging out.
  • digi_owl 10y ago
    Expect them to call it a broken concept, as they did with su.
• cnvogel 10y ago
  nohup (no hangup) just concerns itself with the controlling TTY of a process. By running "nohup", you are not passing on the intent on why this process should be kept alive, and for how long. Traditionally the answer was "forever", but I think it's reasonable to implement lifetimes "for this session", "once the last of my sessions has ended, probably after a timeout" and "forever". (Added:) The first runtime, in systemd parlance (I think), would be the session scope, the second runtime would be the user service and the third... well, something different, as you'd pass on things (group memberships, environment variables, namespaces) from your shell/session into a long-lasting service. One probably would want to extend the "once the last of my session has ended" state to the runtime of the "run forever" command. Most non-technical users, I guess, would really prefer one of the first two lifetimes to be the default. As being able to start from a clean state after logging in- and out is rather convenient. As nohup, in an interactive shell, is used for the third "keep running forever" option, I think it would be reasonable for distributions to alias it to the relevant "systemd-run..." command for all default shells. Then user-expectations would be perfectly met (and scripts will still run the binary /usr/bin/nohup).