Waiting for apt locks without hacky Bash scripts
blog.sinjakli.co.uk
Waiting for apt locks without hacky Bash scripts
1–10 of 30 posts
Re: Waiting for apt locks without hacky Bash scripts
#2[deleted]
Re: Waiting for apt locks without hacky Bash scripts
#3I had exactly the same issue in one of my deploy scripts about 6-7 hours ago and fixed it with the fuser solution you mentioned in the askubuntu thread. What a coincidence haha, I’ll try this out tomorrow, thanks so much :)
Re: Waiting for apt locks without hacky Bash scripts
#4Those darned apt locks have to be the second biggest PITA of my Linux development experience. Who in their right mind thought it was a good idea for an automatic system maintenance process to entirely block the user from doing their using for the first couple minutes after startup? As if that wasn’t enough they have the nerve to log this line:
> Be aware that removing the lock file is not a solution and may break your system.
Guess what? My system is already broken! It’s refusing to do what I want it to do (install a package so that I can test it) in favor of doing what some remote agent (the update service) told it to do.
At this point I just immediately delete the .lock file when I see that message. Never has given me any problems. If it did, I’d just reimage the VM and probably be done sooner than if I had waited for that lock.
Re: Waiting for apt locks without hacky Bash scripts
#5Wow. This would have been useful to have known about. I have worked around that dumb apt lock too many times for it have any meaning to me anymore.
Re: Waiting for apt locks without hacky Bash scripts
#6Coming from Gentoo, encountering Debianesque systems only later, that all-out locking really surprised me.
Portage, the Gentoo package manager, only takes a lock at the very end of the installation, when a file tree (result of compilation etc) is merged into the "live" filesystem - so that those merges are serialized and checked for collisions.
Re: Waiting for apt locks without hacky Bash scripts
#7[deleted]
Re: Waiting for apt locks without hacky Bash scripts
#8Coming from Gentoo, encountering Debianesque systems only later, that all-out locking really surprised me. Portage, the Gentoo package manager, only takes a lock at the very end of the installation, when a file tree (result of compilation etc) is merged into the "live" filesystem - so that those merges are serialized and checked for collisions.
and of course with Gentoo, this problem needed to be solved from the start, otherwise we would've been locked out of using our package manager for a day in 2004 while we were waiting for XFree86 to finish compiling.
Re: Waiting for apt locks without hacky Bash scripts
#9> This all started when I was looking into why instances in an auto scaling group were sometimes failing to bootstrap correctly.
Please use Packer to build your images; don't do it on ASG instance deploy.
If somebody in the company tells you you're not allowed to build your own images, tell them to go fuck themselves, and write an e-mail to that guy's boss's boss explaining how much engineering time you're wasting (and how likely the products are to fail due to ASGs trying to bootstrap systems on the fly) because they won't let you cut an AMI.
Re: Waiting for apt locks without hacky Bash scripts
#10I run large datacenters with thousands of boxes.
I have a little app (written in golang) installed on each box that effectively is a task runner. Tasks can be written to do anything, including apt-get installing software.
If apt-get fails to run, the task fails (context.WithTimeout) and is run again at a later date. No random hacks needed. Everything is built to be idempotent, self-healing and eventually consistent.