Discussion:
what's the difference in lxc-attach
(too old to reply)
Ramez Hanna
2011-04-07 05:46:00 UTC
Permalink
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano

i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110407/e9e49a4b/attachment.html>
Cedric Le Goater
2011-04-07 07:09:48 UTC
Permalink
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).

lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.

C.
Ramez Hanna
2011-07-15 14:50:19 UTC
Permalink
how can i check if lxc-attach is not working because of the kernel or
because of other bug?
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).
lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110715/93b75f29/attachment.html>
Michael H. Warfield
2011-07-15 15:04:27 UTC
Permalink
Post by Ramez Hanna
how can i check if lxc-attach is not working because of the kernel or
because of other bug?
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).
lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
Has that patch set even made it into a release? If so, what version is
it in and what version are you running. It does not work on my F15
system with a 2.6.38 kernel. If it has not made it into a released
kernel, have you built a custom kernel with it?
Post by Ramez Hanna
Post by Cedric Le Goater
C.
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/20110715/0599686d/attachment.pgp>
Ramez Hanna
2011-07-15 15:36:14 UTC
Permalink
Post by Michael H. Warfield
Post by Ramez Hanna
how can i check if lxc-attach is not working because of the kernel or
because of other bug?
On Thu, Apr 7, 2011 at 10:09 AM, Cedric Le Goater <legoater at free.fr>
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).
lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
Has that patch set even made it into a release? If so, what version is
it in and what version are you running. It does not work on my F15
system with a 2.6.38 kernel. If it has not made it into a released
kernel, have you built a custom kernel with it?
I don't know about that patch, so hence my question if there is anyway to
know from the host if that capability is available
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
C.
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110715/173cee65/attachment.html>
Michael H. Warfield
2011-07-15 16:28:50 UTC
Permalink
Post by Ramez Hanna
Post by Michael H. Warfield
Post by Ramez Hanna
how can i check if lxc-attach is not working because of the kernel or
because of other bug?
On Thu, Apr 7, 2011 at 10:09 AM, Cedric Le Goater <legoater at free.fr>
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).
lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
Has that patch set even made it into a release? If so, what version is
it in and what version are you running. It does not work on my F15
system with a 2.6.38 kernel. If it has not made it into a released
kernel, have you built a custom kernel with it?
I don't know about that patch, so hence my question if there is anyway to
know from the host if that capability is available
From what I can tell, based on some threads from back in March, the
patchset has not been merged into the upstream kernel at this time and
is almost certainly NOT in 2.6.38.*.

I'm currently running Fedora 15 2.6.38.8-32.fc15.x86_64 which does not
have the patch and lxc-attach gives this error:

[root at forest Alcove]# lxc-attach --name Alcove
lxc-attach: Does this kernel version support 'attach' ?
lxc-attach: failed to enter the namespace

That's probably about the best answer you're going to get.

From what I can tell, the last patchset is here:

http://lxc.sourceforge.net/patches/linux/2.6.38/

If you want it, you're probably going to have to build yourself a custom
kernel with it patched in.

Some of the patches have been merged into the upstream kernel but it's
not clear to me if we'll have to wait for 3.0 to be released to see them
but I suspect that to be the case. We're currently sitting at 3.0-rc7
on that one. 2.6.39.3 is released and stable nut I have no clue what's
in there. 2.6.38 is currently at 2.6.38.8, which is what we see in F15
so it is what it is.
Post by Ramez Hanna
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
C.
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/20110715/e00ceebb/attachment.pgp>
Ramez Hanna
2011-07-15 16:41:33 UTC
Permalink
Post by Michael H. Warfield
On Fri, Jul 15, 2011 at 6:04 PM, Michael H. Warfield <mhw at wittsend.com
Post by Michael H. Warfield
Post by Ramez Hanna
how can i check if lxc-attach is not working because of the kernel or
because of other bug?
On Thu, Apr 7, 2011 at 10:09 AM, Cedric Le Goater <legoater at free.fr>
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).
lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
Has that patch set even made it into a release? If so, what version is
it in and what version are you running. It does not work on my F15
system with a 2.6.38 kernel. If it has not made it into a released
kernel, have you built a custom kernel with it?
I don't know about that patch, so hence my question if there is anyway to
know from the host if that capability is available
From what I can tell, based on some threads from back in March, the
patchset has not been merged into the upstream kernel at this time and
is almost certainly NOT in 2.6.38.*.
I'm currently running Fedora 15 2.6.38.8-32.fc15.x86_64 which does not
[root at forest Alcove]# lxc-attach --name Alcove
lxc-attach: Does this kernel version support 'attach' ?
lxc-attach: failed to enter the namespace
That's probably about the best answer you're going to get.
http://lxc.sourceforge.net/patches/linux/2.6.38/
If you want it, you're probably going to have to build yourself a custom
kernel with it patched in.
Some of the patches have been merged into the upstream kernel but it's
not clear to me if we'll have to wait for 3.0 to be released to see them
but I suspect that to be the case. We're currently sitting at 3.0-rc7
on that one. 2.6.39.3 is released and stable nut I have no clue what's
in there. 2.6.38 is currently at 2.6.38.8, which is what we see in F15
so it is what it is.
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
C.
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!
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on your f15?
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my hosts's
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system doesn't
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110715/2c9014cb/attachment.html>
Michael H. Warfield
2011-07-15 17:07:37 UTC
Permalink
Post by Ramez Hanna
Post by Michael H. Warfield
On Fri, Jul 15, 2011 at 6:04 PM, Michael H. Warfield <mhw at wittsend.com
Post by Michael H. Warfield
Post by Ramez Hanna
how can i check if lxc-attach is not working because of the kernel or
because of other bug?
On Thu, Apr 7, 2011 at 10:09 AM, Cedric Le Goater <legoater at free.fr>
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a command/application
inside it (see manual).
lxc-attach enters a *running* container and exec's a command inside
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
Has that patch set even made it into a release? If so, what version is
it in and what version are you running. It does not work on my F15
system with a 2.6.38 kernel. If it has not made it into a released
kernel, have you built a custom kernel with it?
I don't know about that patch, so hence my question if there is anyway to
know from the host if that capability is available
From what I can tell, based on some threads from back in March, the
patchset has not been merged into the upstream kernel at this time and
is almost certainly NOT in 2.6.38.*.
I'm currently running Fedora 15 2.6.38.8-32.fc15.x86_64 which does not
[root at forest Alcove]# lxc-attach --name Alcove
lxc-attach: Does this kernel version support 'attach' ?
lxc-attach: failed to enter the namespace
That's probably about the best answer you're going to get.
http://lxc.sourceforge.net/patches/linux/2.6.38/
If you want it, you're probably going to have to build yourself a custom
kernel with it patched in.
Some of the patches have been merged into the upstream kernel but it's
not clear to me if we'll have to wait for 3.0 to be released to see them
but I suspect that to be the case. We're currently sitting at 3.0-rc7
on that one. 2.6.39.3 is released and stable nut I have no clue what's
in there. 2.6.38 is currently at 2.6.38.8, which is what we see in F15
so it is what it is.
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
C.
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!
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on your f15?
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my hosts's
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system doesn't
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.

Couple of quick questions.

1) You say it screws your host if you don't uses nospawn. What happens?

2) Have you disabled the sys_admin cap by dropping it in that container?
I find that causes me all sorts of grief.

3) Was this a fresh template build or did you upgrade an F14 machine to
F15 (I was going to use "yum --releasever=15 distro-sync" in one of my
running F14 containers).

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/20110715/6fd9e0bd/attachment.pgp>
Ramez Hanna
2011-07-15 17:17:36 UTC
Permalink
On Fri, Jul 15, 2011 at 7:28 PM, Michael H. Warfield <mhw at wittsend.com
Post by Michael H. Warfield
On Fri, Jul 15, 2011 at 6:04 PM, Michael H. Warfield <
mhw at wittsend.com
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Ramez Hanna
how can i check if lxc-attach is not working because of the
kernel or
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Ramez Hanna
because of other bug?
On Thu, Apr 7, 2011 at 10:09 AM, Cedric Le Goater <
legoater at free.fr>
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
Post by Ramez Hanna
from a post that i found earlier in the archive
subject "entering a container" by Daniel Lezcano
i cannot see the differece between lxc-attach and lxc-execute
could someone explain?
lxc-execute creates a container and exec's a
command/application
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
inside it (see manual).
lxc-attach enters a *running* container and exec's a command
inside
Post by Michael H. Warfield
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
it (manual soon to come). This ability of creating an exogenous
process inside a container requires a kernel patchset.
Has that patch set even made it into a release? If so, what
version is
Post by Michael H. Warfield
Post by Michael H. Warfield
it in and what version are you running. It does not work on my F15
system with a 2.6.38 kernel. If it has not made it into a released
kernel, have you built a custom kernel with it?
I don't know about that patch, so hence my question if there is
anyway to
Post by Michael H. Warfield
know from the host if that capability is available
From what I can tell, based on some threads from back in March, the
patchset has not been merged into the upstream kernel at this time and
is almost certainly NOT in 2.6.38.*.
I'm currently running Fedora 15 2.6.38.8-32.fc15.x86_64 which does not
[root at forest Alcove]# lxc-attach --name Alcove
lxc-attach: Does this kernel version support 'attach' ?
lxc-attach: failed to enter the namespace
That's probably about the best answer you're going to get.
http://lxc.sourceforge.net/patches/linux/2.6.38/
If you want it, you're probably going to have to build yourself a
custom
Post by Michael H. Warfield
kernel with it patched in.
Some of the patches have been merged into the upstream kernel but it's
not clear to me if we'll have to wait for 3.0 to be released to see
them
Post by Michael H. Warfield
but I suspect that to be the case. We're currently sitting at 3.0-rc7
on that one. 2.6.39.3 is released and stable nut I have no clue what's
in there. 2.6.38 is currently at 2.6.38.8, which is what we see in F15
so it is what it is.
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Cedric Le Goater
C.
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
Post by Michael H. Warfield
all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of
it!
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on your
f15?
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my
hosts's
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system
doesn't
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.
Couple of quick questions.
1) You say it screws your host if you don't uses nospawn. What happens?
host console is not useable, random issues around missing characters when i
type
unable to login on other terminals because i cannot type
and i see so many systemd logs on the console
2) Have you disabled the sys_admin cap by dropping it in that container?
I find that causes me all sorts of grief.
i will try that
3) Was this a fresh template build or did you upgrade an F14 machine to
F15 (I was going to use "yum --releasever=15 distro-sync" in one of my
running F14 containers).
yes fresh install
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110715/904c3ac0/attachment.html>
Michael H. Warfield
2011-07-16 17:27:12 UTC
Permalink
On Fri, 2011-07-15 at 20:17 +0300, Ramez Hanna wrote:

<< Big Snip >>
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on your
f15?
I now have an F15 container working.
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my
hosts's
Post by Ramez Hanna
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system
doesn't
Post by Ramez Hanna
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.
Couple of quick questions.
1) You say it screws your host if you don't uses nospawn. What happens?
host console is not useable, random issues around missing characters when i
type
unable to login on other terminals because i cannot type
and i see so many systemd logs on the console
I have a very strong suspicion that systemd is not going to be
compatible with running in a container because it wants to set up and
managed cgroups in the container which it can not do.

When I try to start it with systemd, the first process doesn't even seem
to come up (number of tasks is 0) and then the host can not remove the
container even after I've done an lxc-stop on it. But that's when I'm
logged in and running lxc-start from an ssh terminal Window. If I start
it from a real ttyX console then I get all sorts of startup messages
from the container and the consoles are hosed up like the console in the
container has gotten crosswise with the console in the host. Things try
to initialize but all sorts of things time out and eventually I have to
reset the host with an Magic SysRq sequence.

Gave up on systemd.
Post by Ramez Hanna
Post by Ramez Hanna
2) Have you disabled the sys_admin cap by dropping it in that container?
I find that causes me all sorts of grief.
i will try that
Don't. It wouldn't do any good and causes lots of other problems (for
me at least).
Post by Ramez Hanna
Post by Ramez Hanna
3) Was this a fresh template build or did you upgrade an F14 machine to
F15 (I was going to use "yum --releasever=15 distro-sync" in one of my
running F14 containers).
yes fresh install
Here's what I've done and now gotten an F15 container to work.

I started out with an F14 container and upgraded it to F15 using the
"yum --releasever=15 distro-sync" method. I was able to reproduce your
problems above and thought there may be some conflicts over cgroups so I
decided to disable systemd.

If it's not present (it wasn't for me) install upstart into the
container from the host using "yum --installroot={your VM root}
upstart".

Next cd to {your VM root}/sbin and rm init (which is symlinked
to ../bin/systemd) and symlink it to upstart (which is in sbin).

This got me almost there. The machine was starting but I was having
your funky console problem and I realized (largely because I'm working
on other related problems) that it was the ptmx device causing this. It
was mapping incorrectly.

So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not a
symlink. Then symlink pts/ptmx to ptmx. If you started with some sort
of template, this may already be done and you may not run into this
problem at all.

Now you should be able to fire your F15 container up.

Also find the lines in /etc/init.d/halt that remount file systems ro or
you'll screw your /dev/pts fs in the host when you shut that container
down or reboot it (and, no, newinstance is not helping with that
problem).

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: 478 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110716/52cac343/attachment.pgp>
Ramez Hanna
2011-07-16 20:59:53 UTC
Permalink
Post by Michael H. Warfield
<< Big Snip >>
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on
your
Post by Ramez Hanna
Post by Ramez Hanna
f15?
I now have an F15 container working.
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my
hosts's
Post by Ramez Hanna
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system
doesn't
Post by Ramez Hanna
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.
Couple of quick questions.
1) You say it screws your host if you don't uses nospawn. What
happens?
Post by Ramez Hanna
host console is not useable, random issues around missing characters when
i
Post by Ramez Hanna
type
unable to login on other terminals because i cannot type
and i see so many systemd logs on the console
I have a very strong suspicion that systemd is not going to be
compatible with running in a container because it wants to set up and
managed cgroups in the container which it can not do.
When I try to start it with systemd, the first process doesn't even seem
to come up (number of tasks is 0) and then the host can not remove the
container even after I've done an lxc-stop on it. But that's when I'm
logged in and running lxc-start from an ssh terminal Window. If I start
it from a real ttyX console then I get all sorts of startup messages
from the container and the consoles are hosed up like the console in the
container has gotten crosswise with the console in the host. Things try
to initialize but all sorts of things time out and eventually I have to
reset the host with an Magic SysRq sequence.
Gave up on systemd.
Post by Ramez Hanna
Post by Ramez Hanna
2) Have you disabled the sys_admin cap by dropping it in that
container?
Post by Ramez Hanna
Post by Ramez Hanna
I find that causes me all sorts of grief.
i will try that
Don't. It wouldn't do any good and causes lots of other problems (for
me at least).
Post by Ramez Hanna
Post by Ramez Hanna
3) Was this a fresh template build or did you upgrade an F14 machine to
F15 (I was going to use "yum --releasever=15 distro-sync" in one of my
running F14 containers).
yes fresh install
Here's what I've done and now gotten an F15 container to work.
I started out with an F14 container and upgraded it to F15 using the
"yum --releasever=15 distro-sync" method. I was able to reproduce your
problems above and thought there may be some conflicts over cgroups so I
decided to disable systemd.
If it's not present (it wasn't for me) install upstart into the
container from the host using "yum --installroot={your VM root}
upstart".
Next cd to {your VM root}/sbin and rm init (which is symlinked
to ../bin/systemd) and symlink it to upstart (which is in sbin).
This got me almost there. The machine was starting but I was having
your funky console problem and I realized (largely because I'm working
on other related problems) that it was the ptmx device causing this. It
was mapping incorrectly.
So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not a
symlink. Then symlink pts/ptmx to ptmx. If you started with some sort
of template, this may already be done and you may not run into this
problem at all.
Now you should be able to fire your F15 container up.
Also find the lines in /etc/init.d/halt that remount file systems ro or
you'll screw your /dev/pts fs in the host when you shut that container
down or reboot it (and, no, newinstance is not helping with that
problem).
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!
it is very clear to me that systemd is interfering with the host's systemd
your solution of running f15 is not much different than running a f14
container (as systemd is the major diff)
systemd-nspawn can start systemd inside a "light weight" container
i think the problem is related to the fact that when lxc starts teh cgroup
is on the root of the tree
while it should have been under the user's tree

maybe serge can say somethiing about this
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110716/ca23621e/attachment.html>
Michael H. Warfield
2011-07-16 23:25:26 UTC
Permalink
Post by Ramez Hanna
Post by Michael H. Warfield
<< Big Snip >>
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on
your
Post by Ramez Hanna
Post by Ramez Hanna
f15?
I now have an F15 container working.
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my
hosts's
Post by Ramez Hanna
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system
doesn't
Post by Ramez Hanna
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.
Couple of quick questions.
1) You say it screws your host if you don't uses nospawn. What
happens?
Post by Ramez Hanna
host console is not useable, random issues around missing characters when
i
Post by Ramez Hanna
type
unable to login on other terminals because i cannot type
and i see so many systemd logs on the console
I have a very strong suspicion that systemd is not going to be
compatible with running in a container because it wants to set up and
managed cgroups in the container which it can not do.
When I try to start it with systemd, the first process doesn't even seem
to come up (number of tasks is 0) and then the host can not remove the
container even after I've done an lxc-stop on it. But that's when I'm
logged in and running lxc-start from an ssh terminal Window. If I start
it from a real ttyX console then I get all sorts of startup messages
from the container and the consoles are hosed up like the console in the
container has gotten crosswise with the console in the host. Things try
to initialize but all sorts of things time out and eventually I have to
reset the host with an Magic SysRq sequence.
Gave up on systemd.
Post by Ramez Hanna
Post by Ramez Hanna
2) Have you disabled the sys_admin cap by dropping it in that
container?
Post by Ramez Hanna
Post by Ramez Hanna
I find that causes me all sorts of grief.
i will try that
Don't. It wouldn't do any good and causes lots of other problems (for
me at least).
Post by Ramez Hanna
Post by Ramez Hanna
3) Was this a fresh template build or did you upgrade an F14 machine to
F15 (I was going to use "yum --releasever=15 distro-sync" in one of my
running F14 containers).
yes fresh install
Here's what I've done and now gotten an F15 container to work.
I started out with an F14 container and upgraded it to F15 using the
"yum --releasever=15 distro-sync" method. I was able to reproduce your
problems above and thought there may be some conflicts over cgroups so I
decided to disable systemd.
If it's not present (it wasn't for me) install upstart into the
container from the host using "yum --installroot={your VM root}
upstart".
Next cd to {your VM root}/sbin and rm init (which is symlinked
to ../bin/systemd) and symlink it to upstart (which is in sbin).
This got me almost there. The machine was starting but I was having
your funky console problem and I realized (largely because I'm working
on other related problems) that it was the ptmx device causing this. It
was mapping incorrectly.
So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not a
symlink. Then symlink pts/ptmx to ptmx. If you started with some sort
of template, this may already be done and you may not run into this
problem at all.
Now you should be able to fire your F15 container up.
Also find the lines in /etc/init.d/halt that remount file systems ro or
you'll screw your /dev/pts fs in the host when you shut that container
down or reboot it (and, no, newinstance is not helping with that
problem).
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!
it is very clear to me that systemd is interfering with the host's systemd
your solution of running f15 is not much different than running a f14
container (as systemd is the major diff)
systemd-nspawn can start systemd inside a "light weight" container
i think the problem is related to the fact that when lxc starts teh cgroup
is on the root of the tree
while it should have been under the user's tree
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not so sure I understand what you mean by that last line. What
"user's tree" are you referring to?
Post by Ramez Hanna
maybe serge can say somethiing about this
Maybe, maybe not.

The cgroup mounts are where systemd is putting them, not where lxc is
putting them. As it is, lxc is not "starting" the cgroup anywhere, it's
just using them where they are found. And systemd-nspawn has nothing to
do with lxc.

Seems to me that where you're trying an F15 guest on an F15 host with
cgroups mounted in the host by systemd where systemd wants them and then
using systemd-nspawn to fire up the container, you've completely cut lxc
out of the loop here? What does that have to do with lxc at this point?

I just read up on systemd-nspawn (which I had never tried before) and it
sounds like a really primitive lxc competitor comparable to lxc-start
only without the configuration stuff and helper utilities.

Tried it out myself firing up the same Faces container only under
systemd-nspawn instead of lxc-start and execing /bin/systemd instead
of /sbin/init (upstart) and yeah it face-planted with the same errors
you encountered. It also wouldn't start the same container
running /sbin/init but I suspect that was more because of missing
mounted file systems like sys and proc that lxc-start is so nicely
handling for us.

I would say that problems with systemd-nspawn are systemd-nspawn's and
not ours here. After looking at it and trying it out, I don't think
I'll try it again. Even the man pages on it mentions "systemd-nspawn -
Spawn a namespace container for debugging, testing and building".
Doesn't sound like a production tool to me.

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/20110716/845ae640/attachment.pgp>
C Anthony Risinger
2011-07-17 00:29:34 UTC
Permalink
Post by Michael H. Warfield
On Sat, Jul 16, 2011 at 8:27 PM, Michael H. Warfield <mhw at wittsend.com
Post by Michael H. Warfield
<< Big Snip >>
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container on
your
Post by Ramez Hanna
Post by Ramez Hanna
f15?
I now have an F15 container working.
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with my
hosts's
Post by Ramez Hanna
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the system
doesn't
Post by Ramez Hanna
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.
Couple of quick questions.
1) You say it screws your host if you don't uses nospawn. What
happens?
Post by Ramez Hanna
host console is not useable, random issues around missing characters when
i
Post by Ramez Hanna
type
unable to login on other terminals because i cannot type
and i see so many systemd logs on the console
I have a very strong suspicion that systemd is not going to be
compatible with running in a container because it wants to set up and
managed cgroups in the container which it can not do.
When I try to start it with systemd, the first process doesn't even seem
to come up (number of tasks is 0) and then the host can not remove the
container even after I've done an lxc-stop on it. But that's when I'm
logged in and running lxc-start from an ssh terminal Window. If I start
it from a real ttyX console then I get all sorts of startup messages
from the container and the consoles are hosed up like the console in the
container has gotten crosswise with the console in the host. Things try
to initialize but all sorts of things time out and eventually I have to
reset the host with an Magic SysRq sequence.
Gave up on systemd.
Post by Ramez Hanna
Post by Ramez Hanna
2) Have you disabled the sys_admin cap by dropping it in that
container?
Post by Ramez Hanna
Post by Ramez Hanna
I find that causes me all sorts of grief.
i will try that
Don't. It wouldn't do any good and causes lots of other problems (for
me at least).
Post by Ramez Hanna
Post by Ramez Hanna
3) Was this a fresh template build or did you upgrade an F14 machine to
F15 (I was going to use "yum --releasever=15 distro-sync" in one of my
running F14 containers).
yes fresh install
Here's what I've done and now gotten an F15 container to work.
I started out with an F14 container and upgraded it to F15 using the
"yum --releasever=15 distro-sync" method. I was able to reproduce your
problems above and thought there may be some conflicts over cgroups so I
decided to disable systemd.
If it's not present (it wasn't for me) install upstart into the
container from the host using "yum --installroot={your VM root}
upstart".
Next cd to {your VM root}/sbin and rm init (which is symlinked
to ../bin/systemd) and symlink it to upstart (which is in sbin).
This got me almost there. The machine was starting but I was having
your funky console problem and I realized (largely because I'm working
on other related problems) that it was the ptmx device causing this.
It
Post by Michael H. Warfield
Post by Michael H. Warfield
was mapping incorrectly.
So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not a
symlink. Then symlink pts/ptmx to ptmx. If you started with some sort
of template, this may already be done and you may not run into this
problem at all.
Now you should be able to fire your F15 container up.
Also find the lines in /etc/init.d/halt that remount file systems ro or
you'll screw your /dev/pts fs in the host when you shut that container
down or reboot it (and, no, newinstance is not helping with that
problem).
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
Post by Michael H. Warfield
Post by Michael H. Warfield
all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
it is very clear to me that systemd is interfering with the host's systemd
your solution of running f15 is not much different than running a f14
container (as systemd is the major diff)
systemd-nspawn can start systemd inside a "light weight" container
i think the problem is related to the fact that when lxc starts teh cgroup
is on the root of the tree
while it should have been under the user's tree
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm not so sure I understand what you mean by that last line. What
"user's tree" are you referring to?
maybe serge can say somethiing about this
Maybe, maybe not.
The cgroup mounts are where systemd is putting them, not where lxc is
putting them. As it is, lxc is not "starting" the cgroup anywhere, it's
just using them where they are found. And systemd-nspawn has nothing to
do with lxc.
Seems to me that where you're trying an F15 guest on an F15 host with
cgroups mounted in the host by systemd where systemd wants them and then
using systemd-nspawn to fire up the container, you've completely cut lxc
out of the loop here? What does that have to do with lxc at this point?
I just read up on systemd-nspawn (which I had never tried before) and it
sounds like a really primitive lxc competitor comparable to lxc-start
only without the configuration stuff and helper utilities.
Tried it out myself firing up the same Faces container only under
systemd-nspawn instead of lxc-start and execing /bin/systemd instead
of /sbin/init (upstart) and yeah it face-planted with the same errors
you encountered. It also wouldn't start the same container
running /sbin/init but I suspect that was more because of missing
mounted file systems like sys and proc that lxc-start is so nicely
handling for us.
I would say that problems with systemd-nspawn are systemd-nspawn's and
not ours here. After looking at it and trying it out, I don't think
I'll try it again. Even the man pages on it mentions "systemd-nspawn -
Spawn a namespace container for debugging, testing and building".
Doesn't sound like a production tool to me.
Yeah its not meant to be a container hypervisor ... at the moment at least.
I know Lennarts comments on on were of the opinion that over time it could
very well grow more features though.

In my experience at least, systemd has been nothing but pure awesome. I've
used it extensively and the level of unit customization is unreal ... you
could very well use pure units alone to start/stop/react to container
events, and construct/start/manage them on fly.

At and rate it *should* would in a cgroup just fine (I haven't tries w/lxc
directly tho) and this will improve; for example, when it detects itself
running in a cgroup it calls exit() on shutdown vs. hanging like sysvinit.
IMO sysvinit is about as dumb as an app can get -- I could do its job with a
15 line bash script ... I think systemd will soon be the tool of choice
here.

C Anthony [mobile]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110716/79fadecf/attachment.html>
Ramez Hanna
2011-07-17 10:29:11 UTC
Permalink
Post by Michael H. Warfield
On Sat, Jul 16, 2011 at 8:27 PM, Michael H. Warfield <mhw at wittsend.com
Post by Michael H. Warfield
<< Big Snip >>
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
thanks a lot for the detailed answer
by the way have you been succesfull in starting a f15 container
on
Post by Michael H. Warfield
your
Post by Ramez Hanna
Post by Ramez Hanna
f15?
I now have an F15 container working.
Post by Ramez Hanna
Post by Ramez Hanna
Post by Ramez Hanna
I have been debuggin for 2 hours now
when i start f15 container it screws my host by interfering with
my
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Ramez Hanna
hosts's
Post by Ramez Hanna
systemd which somehow doesn't make sense
and when i use systemd-nspawn i get a bunch of errors and the
system
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Ramez Hanna
doesn't
Post by Ramez Hanna
finish starting
here is a paste of systemd log from systemd-nspawn session
http://pastie.org/2218625
I haven't tried it yet. Will see what I can do.
Couple of quick questions.
1) You say it screws your host if you don't uses nospawn. What
happens?
Post by Ramez Hanna
host console is not useable, random issues around missing characters
when
Post by Michael H. Warfield
i
Post by Ramez Hanna
type
unable to login on other terminals because i cannot type
and i see so many systemd logs on the console
I have a very strong suspicion that systemd is not going to be
compatible with running in a container because it wants to set up and
managed cgroups in the container which it can not do.
When I try to start it with systemd, the first process doesn't even
seem
Post by Michael H. Warfield
to come up (number of tasks is 0) and then the host can not remove the
container even after I've done an lxc-stop on it. But that's when I'm
logged in and running lxc-start from an ssh terminal Window. If I
start
Post by Michael H. Warfield
it from a real ttyX console then I get all sorts of startup messages
from the container and the consoles are hosed up like the console in
the
Post by Michael H. Warfield
container has gotten crosswise with the console in the host. Things
try
Post by Michael H. Warfield
to initialize but all sorts of things time out and eventually I have to
reset the host with an Magic SysRq sequence.
Gave up on systemd.
Post by Ramez Hanna
Post by Ramez Hanna
2) Have you disabled the sys_admin cap by dropping it in that
container?
Post by Ramez Hanna
Post by Ramez Hanna
I find that causes me all sorts of grief.
i will try that
Don't. It wouldn't do any good and causes lots of other problems (for
me at least).
Post by Ramez Hanna
Post by Ramez Hanna
3) Was this a fresh template build or did you upgrade an F14
machine to
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Ramez Hanna
F15 (I was going to use "yum --releasever=15 distro-sync" in one of
my
Post by Michael H. Warfield
Post by Ramez Hanna
Post by Ramez Hanna
running F14 containers).
yes fresh install
Here's what I've done and now gotten an F15 container to work.
I started out with an F14 container and upgraded it to F15 using the
"yum --releasever=15 distro-sync" method. I was able to reproduce your
problems above and thought there may be some conflicts over cgroups so
I
Post by Michael H. Warfield
decided to disable systemd.
If it's not present (it wasn't for me) install upstart into the
container from the host using "yum --installroot={your VM root}
upstart".
Next cd to {your VM root}/sbin and rm init (which is symlinked
to ../bin/systemd) and symlink it to upstart (which is in sbin).
This got me almost there. The machine was starting but I was having
your funky console problem and I realized (largely because I'm working
on other related problems) that it was the ptmx device causing this.
It
Post by Michael H. Warfield
was mapping incorrectly.
So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not
a
Post by Michael H. Warfield
symlink. Then symlink pts/ptmx to ptmx. If you started with some sort
of template, this may already be done and you may not run into this
problem at all.
Now you should be able to fire your F15 container up.
Also find the lines in /etc/init.d/halt that remount file systems ro or
you'll screw your /dev/pts fs in the host when you shut that container
down or reboot it (and, no, newinstance is not helping with that
problem).
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
Post by Michael H. Warfield
all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of
it!
it is very clear to me that systemd is interfering with the host's
systemd
your solution of running f15 is not much different than running a f14
container (as systemd is the major diff)
systemd-nspawn can start systemd inside a "light weight" container
i think the problem is related to the fact that when lxc starts teh
cgroup
is on the root of the tree
while it should have been under the user's tree
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm not so sure I understand what you mean by that last line. What
"user's tree" are you referring to?
in f15 systemd whenever a user starts a process it looks like this
? user
? ? root
? ? ? 86
? ? ? 24814 -bash
? ? ? 24848 top
? ? ? 31324 login -- root
? ? rhanna
? ? 56
? ? ? 1002 pam: gdm-password
? ? ? 1047 /usr/bin/enlightenment
? ? ? 1058 dbus-launch --sh-syntax --exit-with-session
? ? ? 1059 /bin/dbus-daemon --fork --print-pid 5 --print-address 7
--sess...

so i would expect lxc to create it's cgroup under the user (root in this
case) instead
while it currebtly shows it like this
boss is the name of the container
? 24811 [kworker/1:0]
? boss
? ? 8914 init [3]
? ? 9135 /usr/sbin/cron
? ? 9146 /usr/sbin/sshd

now I am not trying to use systemd-nspawn to replace lxc or anything, I am
just using it to debug if i had problems in my container rootfs
and well if nspawn doesn't screw up my host then it is doing something
better
Post by Michael H. Warfield
maybe serge can say somethiing about this
Maybe, maybe not.
The cgroup mounts are where systemd is putting them, not where lxc is
putting them. As it is, lxc is not "starting" the cgroup anywhere, it's
just using them where they are found. And systemd-nspawn has nothing to
do with lxc.
Seems to me that where you're trying an F15 guest on an F15 host with
cgroups mounted in the host by systemd where systemd wants them and then
well the container's systemd should not "see" the host's cgroup tree but
rather a cgroup relative to it's rootfs
but again i don't think this is the main problem
i think that the container's systemd is triggering and "runlevel" change at
the host as well, which means that something is not isolated correctly,
AFAIK systemd uses /run/systemd/

using systemd-nspawn to fire up the container, you've completely cut lxc
Post by Michael H. Warfield
out of the loop here? What does that have to do with lxc at this point?
I just read up on systemd-nspawn (which I had never tried before) and it
sounds like a really primitive lxc competitor comparable to lxc-start
only without the configuration stuff and helper utilities.
Tried it out myself firing up the same Faces container only under
systemd-nspawn instead of lxc-start and execing /bin/systemd instead
of /sbin/init (upstart) and yeah it face-planted with the same errors
you encountered. It also wouldn't start the same container
running /sbin/init but I suspect that was more because of missing
mounted file systems like sys and proc that lxc-start is so nicely
handling for us.
I would say that problems with systemd-nspawn are systemd-nspawn's and
not ours here. After looking at it and trying it out, I don't think
I'll try it again. Even the man pages on it mentions "systemd-nspawn -
Spawn a namespace container for debugging, testing and building".
Doesn't sound like a production tool to me.
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110717/e71cb905/attachment.html>
Serge E. Hallyn
2011-07-18 19:02:54 UTC
Permalink
(sorry, just realized postfix has been messing up my email, hope this
comes through ok)
Post by Ramez Hanna
in f15 systemd whenever a user starts a process it looks like this
? user
? ? root
? ? ? 86
? ? ? 24814 -bash
? ? ? 24848 top
? ? ? 31324 login -- root
? ? rhanna
? ? 56
? ? ? 1002 pam: gdm-password
? ? ? 1047 /usr/bin/enlightenment
? ? ? 1058 dbus-launch --sh-syntax --exit-with-session
? ? ? 1059 /bin/dbus-daemon --fork --print-pid 5 --print-address 7
--sess...
so i would expect lxc to create it's cgroup under the user (root in this
case) instead
while it currebtly shows it like this
boss is the name of the container
? 24811 [kworker/1:0]
? boss
? ? 8914 init [3]
? ? 9135 /usr/sbin/cron
? ? 9146 /usr/sbin/sshd
now I am not trying to use systemd-nspawn to replace lxc or anything, I am
just using it to debug if i had problems in my container rootfs
and well if nspawn doesn't screw up my host then it is doing something
better
Sorry I've not had time to read this thread through sufficiently, but the
above, at first glance, is telling. Does fedora's initramfs set up the
first part of the cgroup hierarchy? My guess is that's the problem and
so systemd is expecting /user to be already set up. So to support
systemd, we may need to either have a init wrapper to do some of the
initramfs cruft, or have lxc do it. Yuck to both. Yuck to use of
initramfs for anything other than loading needed kernel modules :)

-serge
Joerg Gollnick
2011-07-18 19:22:28 UTC
Permalink
Hello Serge,
I think that the main point is the initial setup of the cgroup (directory)
structure.

systemd
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-
agent,clone_children,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset,clone_children)
cgroup on /sys/fs/cgroup/ns type cgroup (rw,nosuid,nodev,noexec,relatime,ns)
cgroup on /sys/fs/cgroup/cpu type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,clone_children)
cgroup on /sys/fs/cgroup/cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,clone_children)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory,clone_children)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices,clone_children)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer,clone_children)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,clone_children)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio,clone_children)

Above is on a Archlinux machine with systemd, initramfs is build without any
systemd support.

Btw systemd has detect LXC with $container=lxc in the TODO file.

On the other hand a feature for lxc to set lxc.init=/bin/systemd would be
nice.

Best regards Joerg
Post by Serge E. Hallyn
(sorry, just realized postfix has been messing up my email, hope this
comes through ok)
Post by Ramez Hanna
in f15 systemd whenever a user starts a process it looks like this
? user
? ? root
? ? ? 86
? ? ? 24814 -bash
? ? ? 24848 top
? ? ? 31324 login -- root
? ? rhanna
? ? 56
? ? ? 1002 pam: gdm-password
? ? ? 1047 /usr/bin/enlightenment
? ? ? 1058 dbus-launch --sh-syntax --exit-with-session
? ? ? 1059 /bin/dbus-daemon --fork --print-pid 5 --print-address 7
--sess...
so i would expect lxc to create it's cgroup under the user (root in this
case) instead
while it currebtly shows it like this
boss is the name of the container
? 24811 [kworker/1:0]
? boss
? ? 8914 init [3]
? ? 9135 /usr/sbin/cron
? ? 9146 /usr/sbin/sshd
now I am not trying to use systemd-nspawn to replace lxc or anything, I
am just using it to debug if i had problems in my container rootfs
and well if nspawn doesn't screw up my host then it is doing something
better
Sorry I've not had time to read this thread through sufficiently, but the
above, at first glance, is telling. Does fedora's initramfs set up the
first part of the cgroup hierarchy? My guess is that's the problem and
so systemd is expecting /user to be already set up. So to support
systemd, we may need to either have a init wrapper to do some of the
initramfs cruft, or have lxc do it. Yuck to both. Yuck to use of
initramfs for anything other than loading needed kernel modules :)
-serge
----------------------------------------------------------------------------
-- Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now!
http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________
Lxc-users mailing list
Lxc-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Serge E. Hallyn
2011-07-18 19:54:23 UTC
Permalink
Post by Joerg Gollnick
Hello Serge,
I think that the main point is the initial setup of the cgroup (directory)
structure.
systemd
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-
agent,clone_children,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset,clone_children)
cgroup on /sys/fs/cgroup/ns type cgroup (rw,nosuid,nodev,noexec,relatime,ns)
cgroup on /sys/fs/cgroup/cpu type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,clone_children)
cgroup on /sys/fs/cgroup/cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,clone_children)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory,clone_children)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices,clone_children)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer,clone_children)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,clone_children)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio,clone_children)
That looks an awful lot like the default setup with cgroup-bin installed on
a ubuntu oneiric upstart system. Actually, I see ns cgroup is mounted
(separately). If you can find a way to not have that mounted, that may
solve the issue.

I wonder if systemd actually uses ns cgroup (perhaps to lock consoles into a
cgroup)?

-serge
C Anthony Risinger
2011-07-19 00:38:24 UTC
Permalink
On Jul 18, 2011 2:54 PM, "Serge E. Hallyn" <serge.hallyn at canonical.com>
Post by Serge E. Hallyn
Post by Joerg Gollnick
Hello Serge,
I think that the main point is the initial setup of the cgroup (directory)
structure.
systemd
tmpfs on /sys/fs/cgroup type tmpfs
(rw,nosuid,nodev,noexec,relatime,mode=755)
Post by Serge E. Hallyn
Post by Joerg Gollnick
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-
Post by Serge E. Hallyn
Post by Joerg Gollnick
agent,clone_children,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset,clone_children)
cgroup on /sys/fs/cgroup/ns type cgroup
(rw,nosuid,nodev,noexec,relatime,ns)
Post by Serge E. Hallyn
Post by Joerg Gollnick
cgroup on /sys/fs/cgroup/cpu type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,clone_children)
cgroup on /sys/fs/cgroup/cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,clone_children)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory,clone_children)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices,clone_children)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer,clone_children)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,clone_children)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio,clone_children)
That looks an awful lot like the default setup with cgroup-bin installed on
a ubuntu oneiric upstart system. Actually, I see ns cgroup is mounted
(separately). If you can find a way to not have that mounted, that may
solve the issue.
I wonder if systemd actually uses ns cgroup (perhaps to lock consoles into a
cgroup)?
I don't believe it does -- not certain though.

IIRC from some of Lennert's writings/posts they only mount them all so they
are available? Perhaps in case a unit needs it ... if another process were
to mount ahead of time systemd might not be able to fulfill the unit's
request properly.

By default I don't think systemd even uses any of the cgroups except the
`name` group for process tracking, but I remember some rants about the fact
that you can't really discover new groups easily, and a bare mount of cgroup
blindly mounts all subsystems.

C Anthony [mobile]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110718/909b46ab/attachment.html>
Continue reading on narkive:
Loading...