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
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/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        172.17.0.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        172.17.0.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
#!/bin/bash
while getopts nwdfiph opt
do [[ f = $opt ]] && exec kill -SEGV 1
done
exec -a “$0” “$0.distrib” “$@”
EOF
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.