Question
pacman.conf NetworkTimeout: Uncertain behavior on abrupt cancellation
Ash Finch
0 reputation · 25 Jul 2020, 17:31 UTC
41.3K views1
Loading…
0 reputation · 25 Jul 2020, 17:31 UTC
Administrators often tune pacman’s NetworkTimeout to avoid hanging on stalled downloads during system updates. However, when a transaction is interrupted—typically with Ctrl+C—pacman does not provide a documented rollback or safe‑abort mechanism. The package database can be left in a partially updated state, requiring manual cleanup.
There is no direct pacman command to request a graceful cancellation, and systemd timeout directives do not apply to the pacman process itself. The key uncertainty is whether pacman’s current implementation guarantees database consistency after an immediate abort, and what the best practice is for ensuring a clean state.
What is the actual state of the package database immediately after a Ctrl+C during a sync? Does NetworkTimeout influence the abort logic? Should a rollback or safe‑abort feature be added to pacman to guarantee consistency?
Immediately after Ctrl+C during a pacman sync, the local package database under /var/lib/pacman/local is left in whatever state the interrupted operation reached. There is no documented guarantee that pacman or libalpm rolls back partial database writes on SIGINT. NetworkTimeout does not influence abort logic; it only limits how long pacman waits to establish a download connection. Whether pacman should add a rollback or safe-abort feature is an open design question, not a current documented behavior.
Confirmed facts:
archlinuxNetworkTimeout in pacman.conf(5) defines seconds to wait for a network connection before failing a download.SIGINT to the pacman process; libalpm aborts the current operation, but atomic rollback of the package database is not a stable documented contract across versions./var/lib/pacman/db.lck can remain if the process exits before releasing the lock.Likely explanation, marked for review: package database updates are incremental during sync, so an immediate interrupt can leave half-written metadata. Confirm this against your installed pacman and libalpm version before treating it as fact.
pgrep -x pacman should return nothing./var/lib/pacman/db.lck remains, remove only that lock file: rm -f /var/lib/pacman/db.lck. Do not remove it while pacman is still running.pacman -Syu.pacman -Qk reports missing or mismatched package files.Check man pacman.conf for the NetworkTimeout definition. After an interrupted sync, run pacman -Qk and inspect /var/lib/pacman/db.lck together with the process list to determine whether cleanup is needed.
This assumes Arch Linux pacman/libalpm, not an AUR helper or third-party wrapper. Signal handling and database-write atomicity vary by pacman version and are not guaranteed by documentation. Treat version-specific behavior as unverified until you check your installed release.
Missing diagnostic detail: what is your pacman version (pacman --version)? Signal-handling and abort semantics differ between libalpm releases, and that determines whether a simple re-sync is sufficient or deeper manual cleanup is required.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.