Having a rootfs is not a necessary condition for monitoring utmp, since
/var or /var/run can just be remounted inside the container instead. We
should rely on the other two conditions already in place to decide
whether to monitor the utmp file:
- the container was started with 'lxc-start', which indicates that it
has a real init process and is expected to write to a utmp file
- support for CAP_SYS_BOOT was not found in the kernel, which would
otherwise supersede utmp monitoring
Signed-off-by: David Ward <david.w...@ll.mit.edu>
---
src/lxc/utmp.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/lxc/utmp.c b/src/lxc/utmp.c
index b6469b0..a7b9b52 100644
--- a/src/lxc/utmp.c
+++ b/src/lxc/utmp.c
@@ -233,10 +233,6 @@ int lxc_utmp_mainloop_add(struct lxc_epoll_descr *descr,
char path2[MAXPATHLEN];
int fd, wd;
struct lxc_utmp *utmp_data;
- struct lxc_conf *conf = handler->conf;
-
- if (!conf->rootfs.path)
- return 0;
/* We set up a watch for the /var/run directory. We're only interested
* in utmp at the moment, but want to watch for delete and create
--
1.7.1
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
