3 ms·

Sighup already does this by default. You have tools like nohup and tmux that explicitly (as in, you won't do it accidentally) get around this and systemd breaks

• kaba0 4y ago
  No, nohup and tmux are not explicit at all, they simply ignore the signal. The OS has no way of knowing whether it is a frozen process, or one that wants to run in the background. If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them. I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
  • usrn 4y ago
    If you don't install a signal handler the process gets killed frozen or not. The only reason you would ever handle the hup signal is if you want exactly this behavior (user deciding when to terminate the process rather than the OS.) Give me one singular example where this isn't the case. >I recommend No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows. >That's on them No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."
    • kaba0 4y ago
      What if the program does install a signal handler, but it has a race condition and enters an infinite loop? What situation does that correspond to from the POV of the OS? Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
      • usrn 4y ago
        >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.