Sharing my "pacman-unlock" SH

ElectricPrism · 2017-01-01 19:45:05

Create file with contents:
`/usr/bin/unlock-pacman`

#!/bin/sh
sudo rm /var/lib/pacman/db.lck

Set Permissions to Executable

sudo chmod 0755 /usr/bin/unlock-pacman

Now we can issue unlock-pacman instead of sudo rm [....] which helps deture accidental deletion from user input error.

I know it's simplistic but I thought I would share.

JohnBobSmith · 2017-01-01 19:55:34

Could one not also use a Bash Alias for such a simple one-liner? In ~/.bashrc...

alias unlock-pacman='sudo rm var/lib/pacman/db.lck'

Also, this is really trivial to do and already covered in the wiki: https://wiki.archlinux.org/index.php/Pa … 9.22_error. Not sure what that means for this thread...

Slithery · 2017-01-01 20:03:43

This also raises the question why are you having to run this command so often?

I've been running Arch on several machines for years and have never once seen the locked database error.

JohnBobSmith · 2017-01-01 20:08:31

Good point. The easiest way to trigger the error is the following: In Terminal 1, run the following: sudo pacman -Syu. In a second terminal, run the following: sudo pacman -S <software>, in my case, I chose xterm at random. The error appears:

... With a pacman -Syu running in a second terminal ...
[jbs@dmb-gaming-laptop ~]$ sudo pacman -S xterm
error: failed to init transaction (unable to lock database)
error: could not lock database: File exists
  if you're sure a package manager is not already
  running, you can remove /var/lib/pacman/db.lck
[jbs@dmb-gaming-laptop ~]$

Granted, if you have a system update actively running, you should *never* remove the lock!

ayekat · 2017-01-01 23:45:14

JohnBobSmith wrote:

Good point. The easiest way to trigger the error is the following: In Terminal 1, run the following: sudo pacman -Syu. In a second terminal, run the following: sudo pacman -S <software>, in my case, I chose xterm at random. The error appears:
[...]
Granted, if you have a system update actively running, you should *never* remove the lock!

You're describing the exact reason why the lock exists: to prevent concurrent modification of the database.
So yes, there really is no reason why one would ever want to remove that lock.

... unless there is a crash of pacman or an underlying system. Which, under normal circumstances, shouldn't happen so often that it would require an automated workaround solution (→ slithery's question).

ngoonee · 2017-01-02 03:02:23

It can be useful with slower connections as pacman locks on starting downloads. Removing the lock when I know there's going to be enough time allows me to compile an AUR package (or 5) while waiting for downloads to complete.

I believe the lock should really be released during downloads, but it isn't.

Allan · 2017-01-02 07:09:38

The lock during download prevents multiple pacman instances trying to download the same file (which could be fixed by allowing more fine grained locking...)

ngoonee · 2017-01-02 10:13:08

Allan wrote:

The lock during download prevents multiple pacman instances trying to download the same file (which could be fixed by allowing more fine grained locking...)

Oh, I thought the *.part files should be useable for that. Then again there'd be a race condition I suppose.

Allan · 2017-01-02 23:04:28

Can't use .part fils for that. You could not tell a difference between a download that was interrupted and needs continued, or a download that is ongoing.

Arch Linux

#1 2017-01-01 19:45:05

Sharing my "pacman-unlock" SH

#2 2017-01-01 19:55:34

Re: Sharing my "pacman-unlock" SH

#3 2017-01-01 20:03:43

Re: Sharing my "pacman-unlock" SH

#4 2017-01-01 20:08:31

Re: Sharing my "pacman-unlock" SH

#5 2017-01-01 23:45:14

Re: Sharing my "pacman-unlock" SH

#6 2017-01-02 03:02:23

Re: Sharing my "pacman-unlock" SH

#7 2017-01-02 07:09:38

Re: Sharing my "pacman-unlock" SH

#8 2017-01-02 10:13:08

Re: Sharing my "pacman-unlock" SH

#9 2017-01-02 23:04:28

Re: Sharing my "pacman-unlock" SH

Board footer