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