Zypper and Systemd: Concurrent Transaction Lock Handling

Zypper lock wait configuration

In openSUSE Leap 15.6, zypper serializes package operations through an exclusive advisory lock managed by libzypp on /run/zypper.lock (symlinked from /var/run/zypper.lock). When multiple zypper sessions start concurrently, later processes block and retry using flock with a fixed short sleep between attempts. No documented, hidden, or environment-variable configuration exists to adjust this retry interval or set a maximum wait time; the code paths in libzypp's LockManager block indefinitely until the holding process releases or exits.

The lock file resides on a tmpfs mount, meaning it is automatically cleared on every reboot. A common misconception is that a stale /run/zypper.lock left after a SIGKILL blocks future zypper commands. In reality, advisory locks are tied to open file descriptors, not filesystem inodes. When a process is killed with SIGKILL, the kernel releases the lock immediately, and subsequent zypper invocations succeed without issue. The persistent file on disk is harmless and requires no manual deletion for correctness.

No standardized systemd service or tmpfiles.d snippet is shipped with openSUSE Leap 15.6 that actively detects or removes stale zypper locks while the system runs. Adding a timer-based tmpfiles.d rule to delete the file while the system is online creates a race condition: a new zypper process may create the file, the timer deletes it, and another process may contend unpredictably, undermining the lock's purpose.

If zypper commands appear to hang indefinitely, the diagnostic priority is to verify whether a live zypper process still holds the lock, not to inspect the file's presence. Run lslocks | grep zypper or fuser /run/zypper.lock to list processes currently blocking the lock. If no process is reported, the lock is effectively free and the stale file is cosmetic only.

To confirm the behavior in your environment, run zypper --version and rpm -q libzypp to verify you are on Leap 15.6 with libzypp 17.31.x, then execute the lock-check commands above. If a zypper process was recently SIGKILL and you observe subsequent commands failing, the issue is almost certainly a lingering process rather than the lock file itself.

When zypper commands block or fail after a SIGKILL'd session, can you confirm whether any zypper or zypper-related process is still running in the process table? This single detail determines whether no further action is needed or whether a process cleanup is required.