Furthermore, dnf man page should advise what to do about "dnf check" errors
discovered after such premature termination of a transaction (duplicates).

Protecting transactions is really rpm's business. This has been (finally) fixed upstream as a part of larger signal handling rework:
https://github.com/rpm-software-management/rpm/commit/c5f82d3f6223ebd0c5cc0a07ea60393ae7284929

Whether dnf wants to do something in the meanwhile is up to dnf, but given that we've gotten this far with nobody (rpm itself, yum etc) ever doing so, maybe it can wait a couple of more months...

Switching to rpm due to the commit mentioned above.

Frankly, I am a bit skeptical it will suffice to handle that just at
the low level of RPM.  Will provide more feedback when the RPM part
is ready in rawhide.

Anyway, why do you treat SIGINT in other way than SIGQUIT in dnf?
Both default key combos key be pressed accidentally...

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Moving back to rawhide.

rpm >= 4.13.90 currently in rawhide/f27 runs with signals blocked for the duration of rpm-level transaction. Which of course is not quite enough for dnf if it updates its own databases etc after rpm has finished off.

I just exported rpm's rpmsqBlock() in the python bindings (https://github.com/rpm-software-management/rpm/commit/eadee821b3ac97dfaa26e03e9f5cca904bddf00d) but that's not in rawhide yet. With that, dnf doesn't need to compete with rpm's signal handling: you just call rpm.blockSignals(True) when starting a critical phase from *dnf* POV (presumably sometime prior to starting the rpm-level transaction), and then call rpm.blockSignals(False) to unblock them once dnf has finished it's own critical business (presumably sometime after the rpm-level transaction has finished).

The above is now in rawhide so it should be doable from dnf, but just remembered/realized that's kinda the wrong abstraction for rpm to export to python for this purpose. It should export rpmtxnBegin() / rpmtxnEnd(), but that isn't refcounted currently so it needs more work to be usable for this yet.

*** Bug 1490855 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Looks like dnf is still prone to fail when casually interrupted by the
user.

I observe this with "dnf history" run as root and Ctrl-C'ing while the
history runs down the screen:

> Traceback (most recent call last):
>   File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 964, in <lambda>
>     __setattr__ = lambda self, name, value: _swig_setattr(self, TransactionItem, name, value)
> KeyboardInterrupt
> 

-- block mark start --

> The above exception was the direct cause of the following exception:
> 
> Traceback (most recent call last):
>   File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 964, in <lambda>
>     __setattr__ = lambda self, name, value: _swig_setattr(self, TransactionItem, name, value)
>   File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 71, in _swig_setattr
>     return _swig_setattr_nondynamic(self, class_type, name, value, 0)
>   File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 55, in _swig_setattr_nondynamic
>     if type(value).__name__ == 'SwigPyObject':
> SystemError: <class 'type'> returned a result with an error set

-- block mark end --

repeat the above block 979x in this case, then

> The above exception was the direct cause of the following exception:
> 
> Traceback (most recent call last):
>   File "/usr/bin/dnf", line 58, in <module>
>     main.user_main(sys.argv[1:], exit_code=True)
>   File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main
>     errcode = main(args)
>   File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
>     return _main(base, args, cli_class, option_parser_class)
>   File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
>     return cli_run(cli, base)
>   File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run
>     cli.run()
>   File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1107, in run
>     return self.command.run()
>   File "/usr/lib/python3.7/site-packages/dnf/cli/commands/__init__.py", line 991, in run
>     ret = self.output.historyListCmd(self.transaction_ids)
>   File "/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 1604, in historyListCmd
>     num, uiacts = self._history_uiactions(old.data())
>   File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 204, in packages
>     result = self._trans.getItems()
>   File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 879, in getItems
>     return _transaction.Transaction_getItems(self)
> SystemError: <built-in function Transaction_getItems> returned a result with an error set

# rpm -q dnf libdnf rpm
> dnf-4.0.10-1g5bbf4ac2.fc30.noarch
> libdnf-0.24.1-1ga0afd844.fc30.x86_64
> rpm-4.14.2.1-3.fc30.x86_64

Regarding SIGQUIT handling (casually Ctrl-\'ing the process) during
the run of the same command, it terminates while dumping the core,
where the latter is hardly expected.

This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.

Seldom spontaneous/unexpected (core dump as such) responses to SIGQUIT
are still present, though it's not so reliable to reproduce (likely
thanks to [comment 6]):

# dnf update
> ^\Quit (core dumped)m owne     [===        ] ---  B/s |   0  B     --:-- ETA

dnf-4.2.5-4ga5895a85.fc31.noarch
(rpm-4.14.2.1-8.fc31.x86_64)

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.