d4c97ea2f6
There is a small chance that a user sends SIGINT (or any other signal that is trapped) when we're already in clean_up() which used to lead to trap_exit() being executed and the remaining code in clean_up() being skipped due to the bash signal/trap handler blocking EXIT (since its handler is already being executed, even if it's interrupted). In practice, this behaviour caused unexpected results (primarily because pressing ^C at the wrong time left a lock file behind): $ ./repo-add extra.db.tar.gz foobar ==> Extracting database to a temporary location... ^C ==> ERROR: Aborted by user! Exiting... $ ./repo-add extra.db.tar.gz foobar ==> Extracting database to a temporary location... ==> ERROR: File 'foobar' not found. ==> No packages modified, nothing to do. ^C ==> ERROR: Aborted by user! Exiting... $ ./repo-add extra.db.tar.gz foobar ==> ERROR: Failed to acquire lockfile: extra.db.tar.gz.lck. ==> ERROR: Held by process 18522 Fix this and reduce the chance of race conditions in signal handlers by: * Unhooking all traps in both clean_up() and trap_exit(). * Call clean_up() explicitly in trap_exit() to make sure we remove the lock file and the temporary directory even if we send SIGINT when clean_up() is already being executed but didn't reach the unhook code yet. Also, add an optional parameter to clean_up() to allow for setting an explicit exit code when we call clean_up() from trap_exit(). Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> Signed-off-by: Dan McGee <dan@archlinux.org> |
||
---|---|---|
.. | ||
library | ||
po | ||
.gitignore | ||
Makefile.am | ||
makepkg.sh.in | ||
pacman-db-upgrade.sh.in | ||
pacman-key.sh.in | ||
pacman-optimize.sh.in | ||
pkgdelta.sh.in | ||
rankmirrors.sh.in | ||
repo-add.sh.in |