[lxc-devel] Bug? Watching of /run/utmp

[Serge Hallyn]

Quoting Tobias Gruetzmacher (tobias-lists at 23.gs):
> Hi,
> 
> in src/lxc/lxcutmp.c in function lxc_utmp_mainloop_add, lxc tries to set 
> up an inotify watch for /run or /var/run - but only, if I understand the 
> check correctly, if /run/utmp or /var/run exist in the container.
> 
> Since I mount /run as a tmpfs in the container, this check was never true 

When does /run get mounted?  Assuming it gets mounted by the container,
change the code you reference won't help.  The mainloop utmp watcher
gets started before it gets mounted.

What kernel are you running?  If you can get a new enough kernel (which
isn't very new these days) then you shouldn't need the utmp watching at
all, as the container can actually shutdown/reboot itself using the
system call.  You just need to not put sys_boot in lxc.cap.drop.

> and the inotify watch seems to target /var/run (which is a symlink) and 
> never properly picked up utmp. In the end, this prevented containers to 
> shutdown properly (only init left, but lxc doesn't kill it). My current 
> workaround is a lxc.hook.mount script, which does
> 
>   touch "$LXC_ROTFS_MOUNT/run/utmp"
> 
> after mounting the tmpfs on /run.
> 
> IMHO, the check for path2 (starting at line 315 in lxcutemp.c) should be 
> removed.

Hm.  So git-blame points to 4cb05a60 as the commit responsible for this.
Right now I remember.

If you want to change the way this behaves, you'll want to stat
/proc/%d/root/var/run to see if it is a symlink, and if it is a symlink
then get the value using readlink, and make a new path
	ret = snprintf(path3, maxlen, "/proc/%d/root/%s", pid, readlink_result);
and run inotify against that.

But again, unless your tmpfs /run is already mounted at that point
(using a pre-start hook) you will not get inotify notifications on
the utmp file.

-serge