[solved] Location of db.lck file

Maintaining > 600 Arch Linux systems for my company I sometimes run into the well-known problem of having a stray db.lck file from preventing pacman to run.Usually this is due to some SSH connection was interrupted during a previous update attempt, but this is not my point.The problem I run into is, that pacman no longer seems to display the message

if you're sure a package manager is not already running, you can remove /var/lib/pacman/db.lck

From which I used to copy-paste the path to the lock file and remove it – after checking that pacman was not running, of course.Hence I always start to try to remove /var/lock/pacman/db.lck, which obviously does not exist and I have to google every time, where pacman stores this lockfile.

I have three questions in this matter:1) Why was the hint removed?2) May it be added again?3) Why is pacman going against the FHS here and does not store the *lock* file under /var/lock?

Re: [solved] Location of db.lck file

pacman is not going against FHS or any other standard: the location at which this file is stored is a configuration option (DBPath). This is also the place from which you should draw that information, instead of grepping through output intended for humans.

The last question could be restated as “why is a non-FHS directory the default?” Not being among pacman authors prevents me from giving authoritative answer, but since locks are per-database, it seems natural to have them alongside the databases. Hypothetically one could devise a naming scheme that would permit locksfiles in “/var/lock”, but why bother?

Re: [solved] Location of db.lck file

I doubt there is such a bug¹, but the original problem is that you’re taking the wrong route. Fix it and you no longer need to wonder if the message was displayed.

First of all, if a dedicated person is running pacman remotely — as opposed to each user individually on their machine — you know the configuration, because you’re the one who made it. In that fact in mind, you may safely assume it is always “/var/lib/pacman/db.lck”. You may forget about it unles the codebase changes, which will give you unsolveable failures of your own script that has both pacman and locfile-removal failing.

If you want to do it a bit more robust, parse /etc/pacman.conf. You may use conf.c:1050 → conf.c:985 and conf.c:474, ini.c:51 as the reference. Unfortunately there is nothing exported by libalpm or pacman to help you². So either you depend on that algorithm, or possibly make some shortcuts and guesswork — which isn’t very bad, considering what format is being used.

I’ve written “a bit more” and I’m lenient about implementation validity for a good reason. Not only implementing it properly, but merely defining that is not an easy task for a multiuser, uncontrolled environment. Perhaps even impossible. That’s because you are working — most of the time — in undefined state full of race conditions. For that reason alone I would suggest going with the first solution and just hardcoding the path. And finding some organizational solution instead of a technical one.____¹ The standard explanation: no one encountered it, despite it should be widespread if exists.² Strictly speaking you might use pacman --verbose and grep what you need, but this is… eww…

Re: [solved] Location of db.lck file

mpan wrote:

If you want to do it a bit more robust, parse /etc/pacman.conf. You may use conf.c:1050 → conf.c:985 and conf.c:474, ini.c:51 as the reference. Unfortunately there is nothing exported by libalpm or pacman to help you²

...

² Strictly speaking you might use pacman --verbose and grep what you need, but this is… eww…

Re: [solved] Location of db.lck file

schard wrote:

Usually this is due to some SSH connection was interrupted during a previous update attempt, but this is not my point.

It should be your point. And you should use screen or tmux to entirely avoid this and countless other related problems as well. Running an upate under an unreliable ssh connection is a horrible idea, and any progress on finding and eliminating the lock files is just brushing under the rug one symptom of a bigger problem.

Re: [solved] Location of db.lck file

Thank you all for your input.The hint on pacconf is interesting, though it is not installed (yet) on the systems.Regarding the SSH connection, I am about to migrate this to a systemd-unit, so I can just do sth. like "systemctl start pacman-update.service" and do not care about whether the connection aborts after that or not.I'll mark this as solved.

Re: [solved] Location of db.lck file

The upgrades are unattended anyway.Our procedure is to run the upgrade manually on a few staged (pacman -Syuw) systems via pacman -Su and then unattended on the rest.Manually running pacman on > 600 systems could take a lot of time.