[Lxc-users] autodev (was Re: [lxc-devel] [GIT] lxc branch, master, updated.) 7f99e339363d9f005c9386f60a1d8c0953c85053

[Michael H. Warfield]

Serge...

You need to go in for doing psychic readings or buy lots of lottery
ticks because I think you must have been channeling me and reading my
mind.  I've been close to posting on this off and on for the last couple
of days but kept going "I need to test this" and "what about this
combination"...

On Fri, 2012-11-23 at 12:30 -0600, Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hallyn at canonical.com):
> > Quoting Michael H. Warfield (mhw at WittsEnd.com):

...  [big snip]  ...

> > > [root at forest Plover]# cat 2012-10-31-06:41:37.log
> > >       lxc-start 1351680097.900 ERROR    lxc_conf - Operation not permitted - error creating /usr/lib64/lxc/rootfs/dev/tty6
> > > 
> > > Still got the error creating /dev/tty6 but not 1-5.
> > > 
> > > But wait.  In the container itself...
> > > 
> > > [mhw at canyon mhw]$ ssh plover.ip6.wittsend.com
> > > Last login: Tue Oct 30 18:40:12 2012 from canyon.ip6.wittsend.com
> > > [mhw at plover ~]$ sudo -s
> > > [root at plover mhw]# ls -l /dev/tty?
> > > crw-------. 1 root root 136, 36 Oct 31 06:41 /dev/tty1
> > > crw-------. 1 root root 136, 37 Oct 31 06:41 /dev/tty2
> > > crw-------. 1 root root 136, 38 Oct 31 06:41 /dev/tty3
> > > crw-------. 1 root root 136, 39 Oct 31 06:41 /dev/tty4
> > > crw-------. 1 root root 136, 40 Oct 31 06:41 /dev/tty5
> > > crw-------. 1 root root 136, 41 Oct 31 06:41 /dev/tty6
> > > 
> > > So it gave an error but did actual work.

> > What error is it giving?  Does it list the errno?

I meant to track that down to the line that was generating it but the
error what was I gave you...  "Operation not permitted - error
creating /usr/lib64/lxc/rootfs/dev/tty6" and I had not dug into it
deeper.  IAC, with your last change, I consider that error informative
and not critical.  It's just noise...  Seems like it's an "off by one"
error somewhere but I just don't see where...

The error seems to be printed from the statement on line 643 of
lxc/src/lxc/conf.c from that git branch you fed me...

                        if (access(path, F_OK)) {
                                ret = creat(path, 0660);
                                if (ret==-1) {
                                        SYSERROR("error creating %s\n", path);
                                        /* this isn't fatal, continue */
                                } else
                                        close(ret);
                        }


So why does it get this error on the last one and not the previous 5?
No clue.

> > > I've got this narrowed down...  If "devtty" is defined you do one thing
> > > and, if not, you drop into the autodev logic.  Is that correct?  If I
> > 
> > devtty can be used with autodev = 1, and was working fine for me in
> > ubuntu containers using autodev = 1.  I just need to see if I can
> > better consolidate those codepaths.
> > 
> > > use devtty, then the INFO dump says "0 ttys created and, in fact, none
> > > are, so I guess I don't know how to use that parameter.

> > If you say

> > 	lxc.devtty = joe

> > then lxc will create a directory /dev/joe in the container, create
> > /dev/joe/console and /dev/joe/tty{1-N}, bind mount the host ptys
> > to those, and then symlink those into /dev.  The purpose of this
> > sad hackery is to allow package upgrades which want to do

Strange, I tried this for several of my containers and it didn't seem to
actually do anything for me.  The directory was never created and
nothing obvious happened (tip of the hat to the old Colossal Caverns
Adventure game after which my entire domain, WittsEnd, is named).
Orthogonal issue at this point other than your comment about wanting to
add a patch.

> > 	rm /dev/console
> > 	MAKEDEV /dev/console

> > to succeed.  If lxc has bind-mounted the lxc consoles onto /dev/console
> > directly, then 'rm /dev/console' fails because you can't delete the
> > mount target.

> > (This of course results in bad console until a restart with lxc, but
> > let's the container upgrade succeed.  Device namespaces, where are you?)

> Hi Michael,

> This seems to have stalled.  Let's try and get this fixed in staging right
> now.  Was the final patch (which I *believe* was the one in
> https://github.com/hallyn/lxc/tree/upstream.nov1.2012.autodev ) working for
> you?

The patch is working well.  I have some "strangeness" in some containers
which are NOT using systemd that, if I enable audodev when it is NOT
needed, the results have wrong (bad - weird) permissions.  I've looked
right at the code where you do the makedev.  It should work.  It doesn't
make sense.  Maybe it's a 32 bit / 64 bit thing (this is a 64 bit host),
I don't know.  I don't see why but that's an orthogonal issue as well.
It works in the containers I need it and I don't need it in the
containers where it doesn't work so I'm good with the patch as it
stands.

Next issue that's roaring up on us is going to be systemd 195+ and that
whole MS_SHARED and pivot root issue but, again, that's all orthogonal
to this issue.  That's going to bite us in the Fedora 18 time frame and
already in Arch Linux.  But we need this first.

> thanks,
> -serge

Sorry for not reporting back earlier.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20121123/beac2666/attachment.pgp>