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 b

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