Hi,

> The child process's environment should be manipulated the same way
> by lxc-attach as it would be by lxc-start or lxc-execute.

Just a short question: don't you at least want to set PATH to some
sane default such as /usr/local/bin:/usr/bin:/bin or so?

For example, my getent logic introduced in 0.9rc1 will probably fail
if you do this, since it tries to look up the binary using $PATH.

Also, "lxc-attach -n foo -- ls /bin" seems to be a very reasonable
use case and it'd be weird if that failed due to a missing PATH
environment variable when lxc-attach does execvp.

Additionally, if you don't enter the mount namespace
(lxc-attach -s NETWORK for example) and just want to run a local
program, you probably want to keep the environment, because that
program is not really completely inside the container anyway.
Use case: lxc-attach -s NETWORK -n foo -- ip -4 addr add blub
(Using the host's ip utility)

I think cleaning up the environment is generally a good idea, but
the different use cases for lxc-attach have to be thought through
a bit better, simply clearing the environment and setting
container=lxc will only work properly if you spawn a shell that
reads /etc/profile or similar in the container.

(I apologize if this mail comes a cross as a bit negative, I don't
mean it to be, I like the general idea, but what you added breaks a
few things I'm doing with lxc-attach.)

-- Christian


------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Reply via email to