Adam Williamson writes:
It's pretty simple, really: a process running in a terminal
graphical desktop will crash if the terminal app crashes, or if the
desktop crashes, or if X crashes.
It should take me about five minutes to write a process that will continue
happily along if its terminal, desktop, or X crashes. Especially if the
process doesn't need to talk to X in the first place. Like dnf.
I'm quite astonished to read this. Something is wrong, here. Either I have
suffered a stroke, today, or I seriously misunderstood some POSIX
fundamentals, for the last twenty years.
For chrissakes, there's a bleeping program in Fedora called "tmux" that has
managed to accomplished the herculean feat of surviving X shutting down.
I just performed a simple experiment.
1. Opened a terminal window
2. Executed tmux
3. In a tmux session executed "cat >/dev/null"
4. Logged out from the desktop, and only because CTRL-ALT-BACKSPACE has been
disabled "for our convenience", but to the tmux sesssion running in a
terminal this is indistinguishable from losing the X session unexpectedly.
5. Guess what? After logging back in, opening a terminal window, and
executed "tmux attach", I found my "cat" program happily waiting to
more stuff into /dev/null.
Really, the silly excuse that, somehow, X shutting down is a valid reason to
dnf to blow chunks is embarassing. This whole thread is mind-boggling.
I'll be more than happy to eat crow, if proven wrong by pointing out some
detail that I missed; but if I consider anything short of a direct SIGKILL
to a dnf process (or the entire system crashing due to power loss, etc)
ending up with an inconsistent state, to be a BUG.
No, really, I challenge anyone to reproduce this amazing feat of tmux
surviving an unexpected X shutdown and then tell me why dnf cannot do the