[10:14] <larryone1> aloha folks
[10:15] <larryone1> a question
[10:15] <larryone1> I have a bootstrap script that runs an apt-get update and upgrade
[10:16] <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:17] <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:18] <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:19] <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:20] <larryone1> 15.10 and older didn't have this problem
[10:22] <slashbel> does fuser give you any info on who has the lock?
[10:23] <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:25] <slashbel> sorry, i meant which process
[10:26] <larryone1> have thrown in a ps -ef | grep dpkg into the boot script, provisioning a new machine now to see
[10:27] <larryone1> grr, successful provisioning this time
[10:27] <larryone1> WHY WONT YOU FAIL?
[10:53]  * larryone1 continues trying to reproduce the intermittent failure 
[11:55] <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:56] <ebel> larryone: So things like "The file always exists" might not be relevant for whether there is a lock or not.
[14:29] <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:34] <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:35] <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:40] <larryone1> root      1990  1580  0 11:55 pts/1    00:00:00 /usr/bin/dpkg --status-fd 10 --configure tzdata:all
[14:42] <larryone1> yup
[14:42] <larryone1> looks like problem solved
[14:43] <larryone1> ebel, slashbel thanks
[14:44] <ebel> \o/
[14:49] <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