You are not logged in.

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

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 1,933
Website

[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: 1,188
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 seem a bit harsh — don’t get offended too easily!

Offline

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

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 1,933
Website

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: 1,188
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 seem a bit harsh — don’t get offended too easily!

Offline

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

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
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: 1,188
Website

Re: [solved] Location of db.lck file

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

pacconf DBPath

:)


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
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: 1,933
Website

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
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

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: 1,933
Website

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
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
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: 11,868

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 ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#13 2018-11-29 09:10:35

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 1,933
Website

Re: [solved] Location of db.lck file

Just FYI, it happened again.
This time not during some unattended update, but after I aborted packman by a "killall pacman" during its database download phase:

$ LANG=C sudo pacman -Syu
:: Synchronizing package databases...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to update homeinfo (unable to lock database)
error: failed to synchronize all databases
$ pidof pacman
$ sudo rm /var/lib/pacman/db.lck 
$

It still does not print the hint with the DB lock file.
The system is vanilla arch and pretty much up-to-date:

$ LANG=C sudo pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra                                                                                               1681.4 KiB   116K/s 00:15 [#############################################################################] 100%
 community                                                                                              4.7 MiB   115K/s 00:42 [#############################################################################] 100%
 multilib                                                                                             175.5 KiB   118K/s 00:01 [#############################################################################] 100%
 homeinfo is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (1) llvm-libs-7.0.0-2

Total Download Size:   15.48 MiB
Total Installed Size:  63.69 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n] 

It'd be nice to know under what circumstances this hint is not shown for what reason.

Offline

#14 2018-11-29 09:25:04

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,788
Website

Re: [solved] Location of db.lck file

It's shown when pacman can't run a transaction: https://git.archlinux.org/pacman.git/tr … util.c#n78


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#15 2018-11-29 10:44:25

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: [solved] Location of db.lck file

… unless the user has no right to access the directory containing the lock file.

Still, the answer on how to get the name of the file has been provided above, so it doesn’t matter it is not being printed.


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

#16 2018-11-29 10:58:18

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 1,933
Website

Re: [solved] Location of db.lck file

@WorMzy
Thanks for the info.

@mpan
As using sudo to get root access the user should have every right to access the respective directory.
I have memorized where to find the respective file. The question was out of pure curiosity as to why pacman sometimes does not show the hint.

Offline

#17 2018-11-29 15:02:14

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: [solved] Location of db.lck file

Basically you would have to build your own pacman that is patched to log the reason the `access` function fails (that is given by the errno variable), install it instead of the existing one, wait for the situation and see what happens.


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

#18 2018-11-30 09:01:44

apg
Developer
Registered: 2012-11-10
Posts: 211

Re: [solved] Location of db.lck file

You have not reached the point in the operation where a transaction would be started, so the access call is completely irrelevant.

Offline

Board footer

Powered by FluxBB