[lxc-devel] call to setup_dev_symlinks with lxc.autodev

[Michael H. Warfield]

On Thu, 2014-04-17 at 08:59 -0500, Serge Hallyn wrote:
> Quoting William Dauchy (wdauchy at gmail.com):
> > On Wed, Apr 16, 2014 at 9:15 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > > On Mon, 2014-04-14 at 15:18 +0200, William Dauchy wrote:
> > >> but in my case I need to manually access the /dev directory in order
> > >> to make it return EEXIST.
> > >
> > > I don't understand this statement.  What are you doing "in order to make
> > > it return EEXIST?"  Create the symlinks?  In your previous message, you
> > > said the 4 symlinks already exist.  Ok...  Then what does this "I need
> > > to manually access the /dev directory" mean?  What are you doing when
> > > you do?
> > 
> > I was also quoting the code which is calling the `symlink` function
> > and should return EEXIST in order to not fail. The thing is I need to
> > access the directory /dev before starting (see lxc.hook.mount in my
> > config) to make the `symlink` function return EEXIST. That's a
> > workaround to make my container start.
> 
> So doing an 'ls' fills those in?  That's what I don't understand here,
> why would ls create those?

> And simply creating the symlinks on the backing store ahead of time is
> not an option?

I was just going to ask that question.  If that "system disk" is being
created by scripts that are populating why are you (the OP) not creating
those symlinks then?  According to the Linux Kernel documentation, they
are suppose to be there in /dev.  This "system disk" does not comply
with the kernel documentation.

> > I also don't understand what is so difficult to get: it does not make
> > sense to have options to enable/disable creations of stuff in /dev
> > (kmsg/autodev), but not for these four links. That's what I need.
> 
> Ok, I'm fine taking a patch to make those four links depend on autodev.

I would prefer the return with no error choice.

I was just reviewing the original report from Harald Dunkel that
resulted in this code change and it was in the non-autodev case for
CentOS that resulted in the problem.  I subsquently confirmed it in the
Oracle case that the symlinks where missing, also a non-autodev case
while the Fedora case with autodev=1 was perfectly fine.  It's not a
problem in the autodev/systemd case because systemd seems to take care
of that at startup but would still not work if you enabled autodev for
CentOS or Oracle.  That's why we added it to the startup code to catch
all the corner cases with and without autodev.  The missing symlinks
were showing up in two or three distros which were not using autodev.
Making this dependent on autodev=0 will do exactly the wrong thing.

Harald's original report of the missing mandatory symlinks:

On Thu, 2014-02-13 at 14:02 +0100, Harald Dunkel wrote:
> Hi folks,
> 
> Problem in LXC (beta4) running a Centos 6.5 client:
> 
> 	# cat <(echo hello)
> 	cat: /dev/fd/63: No such file or directory
> 
> On a "real" host /dev/fd is a symlink pointing to /proc/self/fd.
> AFAICS only the altlinux template creates this symlink. Debian
> seems to provide the link on its own.
> 
> lxc.autodev = 1 does not help. I tried, of course.

From Dwight's patch for the problem...

On Thu, 2014-02-13 at 16:13 -0500, Dwight Engen wrote:
> The kernel's Documentation/devices.txt says that these symlinks should
> exist in /dev (they are listed in the "Compulsory" section). I'm not
> currently adding nfsd and X0R since they are required for iBCS, but
> they can be easily added to the array later if need be.

When it say's "Compulsory", I read that as "they have to be there".
That's from on high.  They should have been created when the /dev
devices where created.  If the image had not been read-only our code
would have fixed the fact that he doesn't have the mandatory symlinks in
it.  If we change the code to ignore the error on this non-standard
(read that as "broken") image then the OP removes his "hook" and the
symlinks won't exist in his resulting container recursing back to the
errors and problems that Harald was reporting.

Whether we make the change for the error return or not, we should not
make it dependent on autodev.  After reviewing the discussion thread
leading up to the patch, I've concluded that will just open up some of
the corner cases we were trying to cover.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  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-devel/attachments/20140417/d59b5337/attachment.sig>