You are not logged in.

#1 2018-11-08 10:41:57

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 91

[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?

Last edited by schard (2018-11-08 14:08:13)

Offline

#2 2018-11-08 11:16:53

mpan
Member
Registered: 2012-08-01
Posts: 442
Website

Re: [solved] Location of db.lck file

  • It wasn’t. It is there and nothing has changed in that matter since the last update of this feature in 2012.

  • No, as nothing has been removed.

  • 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?


Sometimes I’m a bit harsh — don’t get offended too easily!
PGP: 7C848198AE93D3BB | Coreutils SHA2 performance
Russian roulette: curl "https://ptpb.pw/$(cat /dev/urandom | tr -cd [:alnum:] | head -c 4)" | sudo bash

Offline

#3 2018-11-08 11:34:36

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 91

Re: [solved] Location of db.lck file

Thank you for the insight.
The last times I encountered this issue, the message was not displayed, but the lock file was in place and being the issue.
Hence I suspect that

access(lockfile, F_OK) == 0

must have yielded false.
Unfortunately I have no experience with pacman's code base and don't know what that check does in detail.

Offline

#4 2018-11-08 12:31:46

mpan
Member
Registered: 2012-08-01
Posts: 442
Website

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:1050conf.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…

Last edited by mpan (2018-11-08 12:36:42)


Sometimes I’m a bit harsh — don’t get offended too easily!
PGP: 7C848198AE93D3BB | Coreutils SHA2 performance
Russian roulette: curl "https://ptpb.pw/$(cat /dev/urandom | tr -cd [:alnum:] | head -c 4)" | sudo bash

Offline

#5 2018-11-08 12:49:30

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,768
Website

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:1050conf.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…

Or use pacconf.

Offline

#6 2018-11-08 12:57:22

mpan
Member
Registered: 2012-08-01
Posts: 442
Website

Re: [solved] Location of db.lck file

What Allan means is the pacutils package. Indeed it can:

pacconf DBPath

:)


Sometimes I’m a bit harsh — don’t get offended too easily!
PGP: 7C848198AE93D3BB | Coreutils SHA2 performance
Russian roulette: curl "https://ptpb.pw/$(cat /dev/urandom | tr -cd [:alnum:] | head -c 4)" | sudo bash

Offline

#7 2018-11-08 13:53:08

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 20,284
Website

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.

Last edited by Trilby (2018-11-08 13:54:24)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#8 2018-11-08 14:08:03

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 91

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.

Last edited by schard (2018-11-08 14:09:02)

Offline

#9 2018-11-08 14:25:51

Slithery
Forum Moderator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 2,948

Re: [solved] Location of db.lck file

So instead of fixing the underlying problem like Trilby suggested you're going to run unattended upgrades instead?

What could possibly go wrong.


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#10 2018-11-08 14:36:01

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 91

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.

PS: Just checked: It's currently 797 systems.

Last edited by schard (2018-11-08 14:38:49)

Offline

#11 2018-11-08 20:51:59

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,768
Website

Re: [solved] Location of db.lck file

mpan wrote:

What Allan means is the pacutils package. Indeed it can:

pacconf DBPath

:)

I actually meant pacman-conf which is part of the pacman codebase, previously named pacconf!

Offline

#12 2018-11-09 13:21:18

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 6,362

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.

I hope you have setup your own repo mirror that takes snapshots of a regular mirror so all machines will get the same package versions ?


Multi-init booting with apg Openrc and systemd coexisting
Automounting : not needed, i prefer pmount
Aur helpers : makepkg + my own local repo === rarely need them

Offline

Board footer

Powered by FluxBB