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

[Michael H. Warfield]

On Thu, 2014-04-17 at 10:19 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at WittsEnd.com):

[Snip]

> > 1) Fix the broken image and finish populating the /dev directory in a
> > hook script as you are now doing.
> > 
> > 2) Create the mandatory symlinks when you create the image and fix the
> > existing images on disk.
> > 
> > You've already done #1.  In my mind, that seems like the best solution
> > whether or not you do #2.

> So it sounds like you think that if he had not done either of these and
> lxc had simply ignored the errors, he would have had an error in
> userspace later on?

He might have.  Recurse back to what Harald reported about the /dev/fd
error.  It would depend on a process accessing one of those required
links.

> Perhaps what we need is a clearer error message on the failure.  Does
> someone mind writing the patch to do so?

I'm not so sure.  He didn't give us the error message he got.  I'd like
to see that.  To me, that call to SYSERROR should be sufficient.

I'm just conjecturing at this point but I'm wondering.  Given the
weirdness of just using a hook script doing an "ls" fixes the problem, I
wonder if this is a quirk in the kernel VFS and the symlink call.  Just
conjecturing that maybe if we call symlink and the "newpath" has not
been cached, it's returning something like the EROFS error on the RO FS
and not even checking the link itself.  Doing an ls on {path}/dev causes
it to be cached and then the symlink call then returns EEXITS.  It would
amount to simply the order in which the checks are done way down in the
VFS layer in the kernel and would be a simple corner case.

If that is the case, I'm wondering how much of a mistake it is to
blindly call symlink and depend on its error return and not use stat to
check to see if the target path exists in the first place.  I suspect
that's part of the problem.

> -serge

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/f47fa414/attachment.sig>