[lxc-devel] Commits not showing up in git?

Scott Bronson bronson at rinspin.com
Mon Oct 4 18:49:15 UTC 2010


Hi, this commit and about 8 others haven't showed up in SourceForge's git
tree.

http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=summary

Is there another git tree that the project is using?

Thanks,

    - Scott


On Sun, Oct 3, 2010 at 2:46 PM, Daniel Lezcano <daniel.lezcano at free.fr>wrote:

> The <rootfs>/var/run/utmp is located in:
>
> /proc/<containerinit>/root/var/run/utmp, let's use it.
>
> Signed-off-by: Daniel Lezcano <dlezcano at fr.ibm.com>
> ---
>  src/lxc/utmp.c |   30 +++++++++++++++++++-----------
>  1 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/src/lxc/utmp.c b/src/lxc/utmp.c
> index dca9d72..e6249ce 100644
> --- a/src/lxc/utmp.c
> +++ b/src/lxc/utmp.c
> @@ -82,8 +82,10 @@ static int utmp_handler(int fd, void *data, struct
> lxc_epoll_descr *descr)
>
>        struct lxc_utmp *utmp_data = (struct lxc_utmp *)data;
>
> -       /* we're monitoring a directory. ie->name is not included in
> sizeof(struct inotify_event)
> -        * if we don't read it all at once, read gives us EINVAL, so we
> read and cast to struct ie
> +       /*
> +        * we're monitoring a directory. ie->name is not included in
> +        * sizeof(struct inotify_event) if we don't read it all at once,
> +        * read gives us EINVAL, so we read and cast to struct ie
>         */
>        char buffer[MAXPATHLEN];
>
> @@ -100,7 +102,13 @@ static int utmp_handler(int fd, void *data, struct
> lxc_epoll_descr *descr)
>        ie = (struct inotify_event *)buffer;
>
>        if (ie->len <= 0) {
> -               SYSERROR("inotify event with no name");
> +
> +               if (ie->mask & IN_UNMOUNT) {
> +                       DEBUG("watched directory removed");
> +                       goto out;
> +               }
> +
> +               SYSERROR("inotify event with no name (mask %d)", ie->mask);
>                return -1;
>        }
>
> @@ -161,10 +169,9 @@ static int utmp_get_runlevel(struct lxc_utmp
> *utmp_data)
>        struct utmpx *utmpx;
>        char path[MAXPATHLEN];
>        struct lxc_handler *handler = utmp_data->handler;
> -       struct lxc_conf *conf = handler->conf;
>
> -       if (snprintf(path, MAXPATHLEN, "%s/var/run/utmp",
> conf->rootfs.path) >
> -           MAXPATHLEN) {
> +       if (snprintf(path, MAXPATHLEN, "/proc/%d/root/var/run/utmp",
> +                    handler->pid) > MAXPATHLEN) {
>                ERROR("path is too long");
>                return -1;
>        }
> @@ -211,19 +218,20 @@ static int utmp_get_ntasks(struct lxc_handler
> *handler)
>  int lxc_utmp_mainloop_add(struct lxc_epoll_descr *descr,
>                          struct lxc_handler *handler)
>  {
> -       struct lxc_conf *conf = handler->conf;
>        char path[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
> events as well.
> +       /* 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
> +        * events as well.
>         */
> -       if (snprintf(path, MAXPATHLEN, "%s/var/run", conf->rootfs.path) >
> -           MAXPATHLEN) {
> +       if (snprintf(path, MAXPATHLEN, "/proc/%d/root/var/run",
> +                    handler->pid) > MAXPATHLEN) {
>                ERROR("path is too long");
>                return -1;
>        }
> --
> 1.7.0.4
>
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20101004/3a316752/attachment.html>


More information about the lxc-devel mailing list