Chris Adams writes:
Once upon a time, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> said: > I can make any process survive an X shutdown, using an amazing tool > called "tmux". > > Why can't dnf do the same? Because dnf would have to reimplement tmux's (or screen's) TTY handling, which is far outside the scope of a package manager. If you want to run dnf under tmux/screen, then run it under tmux/screen.
By my rough estimate, the relevant bits of "TTY handling" that are needed to survive the terminal going away comprise no more than four or five system calls.
> You do not need atomic updates to install a signal handler for > SIGHUP or SIGTERM. And maybe issue a setsid() call, beforehand. That's not enough. dnf prints running information to standard out/error, which are connected to the terminal via a TTY. As soon as the terminal process is killed, the TTY is closed, and the next write by dnf will cause an error.
Mea culpa. I forgot about SIGPIPE, my fault. Ok, let's just add SIGPIPE to the list of blocked signals.
I'm up to six system calls, now.
Now, the error could be ignored, but it is hard to say there's a legitimate path to follow after such an error. A system-level program like dnf should generally not ignore such errors. Any RPM script that writes to standard out/error (they're not supposed to do that, but some do, sometimes inadvertently) will also fail.
Splendid. Have the scripts' stdout redirected to a pipe, that dnf will read, and attempt to log it to the terminal on its own, and deal with the fallout.
If you want dnf to survive the terminal exiting, run it under something that handles that, like tmux or screen. Heck, alias dnf to "screen dnf" (or the tmux equivalent) if you like. Don't try to make dnf reimplement all that functionality.
Okee-dokee. That's a reasonable proposition. But only if "reasonable" is defined in a fairly limited way; namely "work-around for lack of resilience and fault tolerance in a criticial system update tool".
Attachment:
pgpjuEDKhDxqE.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
