[lxc-devel] [PATCH 1/1] lxc/conf.c Heuristic determination of autodev condition...

[Michael H. Warfield]

On Thu, 2013-10-03 at 23:30 +0100, Christian Seiler wrote: 
> Hi there,
> 
> > The initial heuristic, in this case, is the existence
> > of /etc/systemd/system in the container to enable autodev.  This is 
> > the
> > heuristic used in the lxc-fedora template but it applicable to all
> > systemd containers, as far as I can determine.

> Just a quick note about the specific implementation (I don't
> have an opinion on the merits of having such a heuristic):
> I think that checking for /etc/systemd/system is not necessarily
> a good idea to detect systemd. The reason is that for example
> Debian Wheezy (and older SuSE versions and probably lots of other
> things out there) can have that directory, while still using
> sysvinit. The reason is that since the distribution allows for
> switching between systemd and sysvinit (and in Debian's case
> also upstart), some packages come with files for all of the
> different init systems. And while unit files in general are
> located in /lib/systemd and not /etc/systemd, the symlinks for
> aliases are actually created in /etc (at least for Debian). So
> this will use autodev not only for systemd-based distros, but
> also for Debian. (Which probably wouldn't be much of a problem
> I guess, but it defeats the purpose of your heuristic.)

Well, in principle, autodev SHOULD work properly even with non-systemd
based distros and may be highly desirable for any other host or
container distro utilizing devtmpfs.  The problem is that, with systemd
based distros, systemd tries to mount devtmpfs on /dev in the container
unless /dev is on another device.  Right now, we're using tmpfs.  I'm
working on patches (that are working in the same limited sense as tmpfs)
to use subdirectories off of a devtmpfs mount to /dev in the host.  Most
containers that do not attempt to mount devtmpfs should not care.  They
will get their devices and this may even enable us to provide dynamic
devices ala udev into the container space from the host (which is not
possible with the tmpfs solution and is difficult with the static fs
solution).

I sort of like the idea of doing the readlink but I'm a little concerned
about having the "systemd" magic cookie in the string sort of thing.
OTOH, looking for the magic cookie of /etc/systemd/system isn't much
better, I will admit.  Since it's a heuristic, and, in principle,
autodev should not have any negative impacts on /dev in the container
(especially when we have it mapped onto a subdirectory of devtempfs),
I'm now sure where the downside is here.  What would be the consequences
of "getting it wrong"?  I am concerned about inconsistent behavior, and
you have a valid point there.  But systemd can have a very strong
negative impact on the host if autodev is not enabled when it might be
running.

> I think a better heuristic would be (very pseudo-y code):

> if autodev < 0
>    if readlink("/sbin/init") contains "systemd"
>         goto possibly_autodev

Not sure how I would implement that readlink in C code.  What if a
distro  installs systemd as init without the symlink?

>    else if lxc-start command cotains "systemd"
>         goto possibly_autodev

I don't think this case is one we're worried about but it's easy to add
as an additional heuristic.

>    else
>         autodev = off
>         goto end
>    end if
> 
>    possibly_autodev:
>         if lxc.mount / lxc.mount.entry contain an entry for
>         /dev
>              autodev = off
>         else
>              autodev = on
>         end if

No, wait...  We already have an lxc.autodev option.  Now your adding
another option?  All I've done is given the ability of audodev to
heuristically switch.  It can be controlled explicity with lxc.autodev =
0 for off and lxc.autodev = 1 for on already.  This merely adds a
heuristic to the default that already exists.

>    end:
> end if

> (Btw. do I see correctly that there is currently no
> configuration option, to specify the default command for
> lxc-start? I think that whould be neat if such a thing
> existed.)

That's an orthogonal issue.  But an interesting point.

> -- Christian

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-devel/attachments/20131003/cb7a96f5/attachment.pgp>