Yay deadlock... shouldn't give up should keep trying

General system Newbie
1 
==> Leaving fakeroot environment.
==> Finished making: vscodium-git 1.88.1.24104.r0.gac0f6f2-1 (Wed 24 Apr 2024 08:27:47)
==> Cleaning up...
[sudo] password for user: 
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
 -> error installing: [/home/coenraad/.cache/yay/vscodium-git/vscodium-git-1.88.1.24104.r0.gac0f6f2-1-x86_64.pkg.tar.zst /home/coenraad/.cache/yay/vscodium-git/vscodium-git-debug-1.88.1.24104.r0.gac0f6f2-1-x86_64.pkg.tar.zst] - exit status 1

So… this took quite a while and just had another window sitting at

:: Proceed with installation? [Y/n]

Two improvements. For the former case, don’t give up after one try. The latter, release the lock?

Feasible?

2

Also where is the yay issue tracker? Thanks

3

So what’s the issue?

4

The issue is that after a lengthy build, the install step fails. Sometimes because it times out waiting for sudo, sometimes because another install is running and there’s a lock file.

Which necessitates (often) the same lengthy build process. Which is a waste of resources, and time…

5

Those points are both by design.

You can use the option --sudoloop with yay. That will keep it from timing out during long operations. Alternatively, you can set that option in yay’s config.

Or globally change the sudo timeout.

2 Likes
6

So what would be the harm in not having the sudo request fail or time out after one failure?

Or releasing the lock while waiting?

7

I edited my post with a post from Dalto from another thread.

8

Awesome! Thanks… !!! curious why this is not a default though? Did it cause problems somewhere?

9

I guess it’s security reasons. For the lock issue always make sure pacman or yay is not running in another terminal and if it isn’t just remove the lock.

10

My question is why do you have two instances running concurrently in the first place? Would you mind clarifying? Just trying to understand the context.

2 Likes
11

Because some of the git installs take up to 20-30 minutes, and I want to use other things that are not yet installed in the mean time.

But I don’t want to have to reinstall the failed installs that I started earlier. Sometimes I forget to complete them, and I get to a situation where I’ve been trying to install something for weeks, and its still not installed, because I don’t spend enough time here… leading me to perpetually work on a suboptimal system, leading me to never quite getting around to complete the curated package list I want preinstalled on all my machines… hope that makes sense. Just a small frustration, I’m sure I’m not alone… maybe just the only person taking the time to try to improve it for others in the same situation…

12

You could install the binary instead of the git version of the AUR package. So instead of vscodium-git install vscodium-bin.

13

Or you should simply learn how to use makepkg and not rely on an AUR helper. That way you can build the package and install it later. On another note, if a build with yay succeded and pacman couldn’t install it because of another instance running, the package is still build.

If the build fails that sucks, sure, but you shouldn’t have to compile it again if it succeeds but not installs.

I don’t really understand your problem.

3 Likes
14

That’s just one example, some don’t have binary distributions yet… if they’re great I’ll try to change that… I just haven’t made up my mind if I want them part of my regular apps yet, because I haven’t been able to evaluate them yet.

But --sudoloop is great. I actually do have that on my laptop, just forgot for a moment that I can go man yay and /sudo to find it… or maybe I was just craving a more human way of doing that :slight_smile:

Still, wondering if it can cause issues if it is a default?

15

Ah, you’ve nailed why I’m so triggered by this. A month or so ago I was stuck in this loop with … I think it was a firefox derivative browser that failed, and it failed after so many hours of compiling that I had tuned out and only saw the sudo failure and not the build failure… so I think I was confusing the two.

Edit: wait, that doesn’t make sense. Under which circumstances will the build get deleted? Does it delete it if I say “don’t keep” the build artifacts? Maybe I did that.

Edit: no can’t be that either. Must’ve been a prerequisite. I really can’t remember, I only remember the pain :frowning_face:

16

That’s the problem. The database lock file exists for a reason, do not run more than one instance of pacman, that’s a sure way to break your system.

3 Likes
17

Yes, depending on the circumstances, it can be a major security issue, or it can be pretty harmless. The default is reasonable here, to err on the safe side.

3 Likes
18

Thanks for clarifying.

To answer your question, the locks are used to prevent race conditions that will lead to a corrupt pacman database, which potentially results in a broken system. Having concurrent processes manipulating the database files simultaneously is a bad idea because one process might step over the other process’ work, leading to a corrupt database.

The best solution for your use case is to simply build your AUR packages manually. For example, let’s say an AUR package X takes a very long time to build. What you can do here is, instead of using an AUR helper (which will try to update every single thing in one go), you can update your normal packages first with pacman. And then after that, build X with makepkg. That way, you can use your system with the latest packages when makepkg is building X. The idea here is to perform each operation separately.

Personally, I don’t care much for AUR helpers. My preferred solution is to manage AUR packages manually and then use rebuild-detector.

4 Likes
19

If you really want to build multiple AUR packages concurrently, try using makepkg. I’ve never tried to build multiple packages concurrently, but I think it should work.

1 Like
20

Thanks I understand things a lot better now.

I still think the UX is bad though, rather than spend hours building and then failing, it should just not build at all if another instance is already running.

But as I understand, it builds the package using makepkg, without touching pacman, and it’s just the pacman step that fails… my only question really is why it doesn’t loop over the pacman step until its done, or you manually cancel it (which I argue that you’d never do unless you changed your mind about wanting to install this package in the meantime).

I still haven’t found the yay repo or bug tracker…