Chris Adams writes:
Once upon a time, Sam Varshavchik <mrsam(a)courier-mta.com>
> 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
> 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
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".