| larryone1 | aloha folks | 10:14 |
|---|---|---|
| larryone1 | a question | 10:15 |
| larryone1 | I have a bootstrap script that runs an apt-get update and upgrade | 10:15 |
| larryone1 | occasionally failing, complaining about /var/lib/dpkg/lock | 10:16 |
| slashbel | hello larryone1! | 10:16 |
| larryone1 | but I seem to be able to apt-get my stuff even when the file is there | 10:16 |
| larryone1 | and the lock file is still there without any dpkg proc running | 10:16 |
| larryone1 | hi slashbel | 10:17 |
| larryone1 | _o/ | 10:17 |
| slashbel | it's complaining about an existing lock file or that it cannot create a lock file? | 10:17 |
| larryone1 | the file always exists, but the timestamp does change on a successful apt-get upgrade | 10:17 |
| larryone1 | E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable) | 10:18 |
| larryone1 | E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it? | 10:18 |
| larryone1 | that error seems to suggest it's complaining about the existence of the lock | 10:18 |
| slashbel | iirc there is a dæmon in Ubuntu which checks for updates, that would grab a lock | 10:19 |
| larryone1 | this only started when we began replacing machines with 16.04, so am suspecting there's something new doing this | 10:19 |
| larryone1 | 15.10 and older didn't have this problem | 10:20 |
| slashbel | does fuser give you any info on who has the lock? | 10:22 |
| larryone1 | might add that check to the boot script and see | 10:23 |
| larryone1 | the file is always owned by root from what I can see | 10:23 |
| slashbel | sorry, i meant which process | 10:25 |
| larryone1 | have thrown in a ps -ef | grep dpkg into the boot script, provisioning a new machine now to see | 10:26 |
| larryone1 | grr, successful provisioning this time | 10:27 |
| larryone1 | WHY WONT YOU FAIL? | 10:27 |
| * larryone1 continues trying to reproduce the intermittent failure | 10:53 | |
| ebel | larryone: I don't know how dpkg works, but I think there's a "file lock" thing in Unix. | 11:55 |
| ebel | larryone: i.e. it actually does some system call to create a file. It doesn't just look at whether the file exists | 11:55 |
| ebel | larryone: So things like "The file always exists" might not be relevant for whether there is a lock or not. | 11:56 |
| larryone1 | ebel, so there might be some sort of file attribute that gets changed or something | 14:29 |
| larryone1 | ? | 14:29 |
| ebel | larryone1: yeah, or some sort of unix kernel magic | 14:29 |
| larryone1 | threw this into my bootstrap script: | 14:34 |
| larryone1 | ps -ef | grep dpkg > /root/dpkg-ps.out | 14:34 |
| larryone1 | got | 14:34 |
| larryone1 | root 2006 1990 0 11:55 pts/1 00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/tzdata.postinst configure 2016d-0ubuntu0.16.04 | 14:34 |
| larryone1 | so it looks like there's some foo that it does on first boot | 14:34 |
| larryone1 | ...or maybe even every boot | 14:35 |
| larryone1 | nonetheless, looks like I might need to put some kind of condition in my provisioning script to not do aptish stuff if there's dpkg things happening | 14:35 |
| larryone1 | root 1990 1580 0 11:55 pts/1 00:00:00 /usr/bin/dpkg --status-fd 10 --configure tzdata:all | 14:40 |
| larryone1 | yup | 14:42 |
| larryone1 | looks like problem solved | 14:42 |
| larryone1 | ebel, slashbel thanks | 14:43 |
| ebel | \o/ | 14:44 |
| larryone1 | looks like the check is not for the file's existence, but whether the file handle is open | 14:49 |
| larryone1 | lsof | grep dpkg | 14:49 |
| larryone1 | ^^ that in the bootstrap script confirmed | 14:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!