Prevent DNF from terminating on a terminal loss

[ppisar]

If DNF losses a terminal, e.g. when an SSH session aborts, DNF is receives SIGHUP from kernel and terminates according to a default disposition for SIGUP. If DNF is running an RPM transaction at that time, the transaction crashes leaving RPM database in undefined state.

While this is not technically a DNF problem (this is how all processes behave in UNIX world) and it can be prevented by a user proactively running DNF in a terminal multiplexor (e.g. screen, tmux), it's good idea to make DNF more resilient if possible.

One approach is ignoring SIGHUP signal, or detaching from the terminal before commencing the RPM transaction. This is a feature request to enhance DNF in this way. Reporting DNF progress to the current terminal needs to be preserved.

When implementing this feature it would be great to verify that concurrently running DNF is correctly prevented from changing DNF and RPM databases.

As a stretch goal, it would be great to enhance error message about concurrently running DNF that the user can watch its progress in DNF log, or the later DNF instance could present /var/log/dnf.log content to the output. (A more stretching goal would be storing DNF output to a separate log file and replying it to a terminal instead of the /var/log/dnf.log.)

[jan-kolarik]

Seems related to https://issues.redhat.com/browse/RHEL-1235.