I realize that my own use case may seem like a very unlikely set of circumstances, but I don't think it's that crazy if you generalize it a bit. The point is that running `makepkg -si` from ansible isn't impossible. Sure, maybe you shouldn't do it, but people will. Ansible suppresses stdout/stderr. This is 100% WONTFIX as far as the ansible people are concerned. So saying that makepkg is trying very hard to tell you about it's infinite loop isn't really very satisfying. Now, I can't be the only person who's ever had a stray lockfile left around by a pacman operation that went wrong. Like I was midway through downloading a bunch of updates and my laptop ran out of power of something. It happens. Now I can fix this on my laptop easy enough, but the use case for ansible is keeping my 80 servers in sync. The idea that one of these is going to have a stray lockfile from something going wrong isn't inconceivable. But as far as I can tell, there's no way to say `pacman --am-i-locked-if-so-exit-1`. Which is maybe what we actually want here; it's fair enough to expect the guy writing ansible scripts to know how to record variables from commands, to be able to look up this flag in the pacman manual page, and only proceed with makepkg if the test is ok. What I don't think is desirable is requiring our hero to manually test for the existence of /var/lib/pacman/db.lck. For one thing, I don't think this file is referenced anywhere in the pacman documentation. It's not in any of the man pages. `man -K db.lck` turns up nothing. Frankly, I don't even remember how I know about it. Probably I poked around trying to fix a bad lock & found it. I'm not sure Eli's workaround meets the case given that we're talking about running `makepkg -si`. It would work if there were no deps & I didn't have to run `makepkg -s && makepkg --packagelist`, but if I do, I think this will infinite loop just as much as otherwise, since both pass through run_pacman. Frankly, I'm not really sure why waiting in a loop for pacman to unlock forever is even desirable to begin with. I tend to think it should just fail fast. This prevents this whole journey of discovery from occuring in the first place. We never have to figure out why it's looping forever. But given that it already works this way, a flag to disable it seems reasonable. Or a way to just ask pacman if it's locked. Or something. For example, if you were to move the looping logic into pacman itself, and I could set an env var which would ensure that it didn't loop, that would probably work.