Comment 0 for bug 1527710

I have a work flow (curtin installation) that does something to the affect of:
 mount $DEVICE /target
 mount --bind /dev /target/dev
 chroot /target apt-get update
 umount /target/dev
 umount /target/

With xenial, I started having failures on the umount of /target/dev because of open file handles.
An lsof showed me that /usr/lib/update-notifier/update-motd-updates-available had open file handles on /dev/null and apt-check had handles on /dev/urandom.

I admit that part of this is my fault, because we do a selective apt-get update (only pulling deb sources, not deb-src). As a result, when /usr/lib/update-notifier/update-motd-updates-available there was possibly more work to be done then would normally have to be done... not sure on that.

For the record, what we do is in http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/util.py#L486 (apt_update method).

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: update-notifier-common 3.164
ProcVersionSignature: User Name 4.3.0-2.11-generic 4.3.0
Uname: Linux 4.3.0-2-generic x86_64
ApportVersion: 2.19.3-0ubuntu2
Architecture: amd64
Date: Fri Dec 18 18:02:41 2015
Ec2AMI: ami-0000072f
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: None
Ec2Ramdisk: None
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: update-notifier
UpgradeStatus: No upgrade log present (probably fresh install)