Docker Community Forums

Share and learn in the Docker community.

Empty utmp database on Ubuntu container

Hi guys,

I’ve deploy an Ubuntu container and I’ve seen utmp db is empty is I run bash using docker exec, it seems to be created but it doesn’t contain any data of the local users.

root@c38f4a0304f3:~# last -f /run/utmp

utmp begins Fri Mar 19 11:40:49 2021
root@c38f4a0304f3:~# last -f /var/log/wtmp

wtmp begins Fri Apr  2 08:53:15 2021
root@c38f4a0304f3:~# cat /etc/passwd
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin

I tried connecting to the same container through ssh and the db is populated

root@34c556674ec3:~# last -f /run/utmp
root     pts/1       Wed Apr  7 11:55   still logged in

utmp begins Wed Apr  7 11:55:20 2021
root@34c556674ec3:~# last -f /var/log/wtmp
root     pts/1       Wed Apr  7 11:55   still logged in

wtmp begins Wed Apr  7 11:55:20 2021

Why is it so? Is it an expected behaviour?

Thanks for your help :slight_smile:

As at Ubuntu 10.04 with lxc 0.7.2, lxc-start detects that a container
has halted by 1) seeing a reboot event in /var/run/utmp; or
2) seeing 's PID 1 terminate.

Ubuntu 10.04 simply REQUIRES /var/run to be a tmpfs; this is hard-coded
into mountall’s (upstart’s) /lib/init/fstab. Without it, the most
immediate issue is that /var/run/ifstate isn’t reaped on reboot, ifup(8)
thinks lo (at least) is already configured, and the boot process hangs
waiting for the network.

Unfortunately, lxc 0.7’s utmp detect requires /var/run to NOT be a
tmpfs. The shipped lxc-ubuntu script works around this by deleting the
ifstate file and not mounting a tmpfs on /var/run, but to me that is
simply waiting for something else to assume /var/run is empty. It also
doesn’t cope with a mountall upgrade rewriting /lib/init/fstab.

More or less by accident, I discovered that I can tell lxc-start that
the container is ready to halt by “crashing” upstart:

container# kill -SEGV 1

Likewise I can spoof a ctrl-alt-delete event in the container with:

dom0# pkill -INT lxc-start

I automate the former signalling at the end of shutdowns thusly:

chroot $template_dir dpkg-divert --quiet --rename /sbin/reboot
chroot $template_dir tee >/dev/null /sbin/reboot <<-EOF
while getopts nwdfiph opt
do [[ f = $opt ]] && exec kill -SEGV 1
exec -a “$0” “$0.distrib” “$@”
chroot $template_dir chmod +x /sbin/reboot
chroot $template_dir ln -s reboot.distrib /sbin/halt.distrib
chroot $template_dir ln -s reboot.distrib /sbin/poweroff.distrib

I use the latter in my customized /etc/init.d/lxc stop rule.
Note that the lxc-wait’s SHOULD be parallelized, but this is not
possible as at lxc 0.7.2 :frowning: This means that theoretically the nth
container gets n?10min to halt, although in practice I find most
containers go down in a decisecond or two.