>What if it crashes If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for

>What if it crashes If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for handling it in an interactive program is because you want that program to persist when the tty goes away and almost the only things that do this are tools like nohup and tmux, not the processes that run inside them) then your crashed program is going to be killed by the hup signal when the user closes their terminal. Yes you can contrive pathological examples, yes signals are hacky in general. You're never going to be able to come up with a real problem with this other than "misusing tmux and nohup to manage deamons instead of initd causes problems." There isn't a legitimate problem with handling the hup signal for interactive tools when the user is expecting it. >RE: Discerning between states Yeah if you want the OS to manage a process for you write a service. I'm not going to write a service for everything I do interactively that needs to not die if there's a network problem. Again, because you seem to be missing it, handling the hup signal in an interactive program is just a way to tell the OS that the user is managing the program themselves. If the user does this and then decides not to manage it, "that's on them." And finally, the real problem here is that systemd breaks stuff like this all the time and makes the platform unpredictable unless you spend time reading the release notes.