You are not logged in.
Pages: 1
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
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
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
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…
Last edited by mpan (2018-11-08 12:36:42)
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
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…
Or use pacconf.
Offline
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
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
So instead of fixing the underlying problem like Trilby suggested you're going to run unattended upgrades instead?
What could possibly go wrong.
Offline
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
I actually meant pacman-conf which is part of the pacman codebase, previously named pacconf!
Offline
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
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
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
… 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
@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
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
You have not reached the point in the operation where a transaction would be started, so the access call is completely irrelevant.
Offline
Pages: 1