Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
Can you tell me the exact git tree and branch you are using? The results you're getting don't make sense to me... Hoping I can find a simple answer. -serge -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Wed, 2012-10-31 at 18:15 +0100, Serge Hallyn wrote: Can you tell me the exact git tree and branch you are using? I'm using head. I'm not specifying a tree. The results you're getting don't make sense to me... Hoping I can find a simple answer. Me too. -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! signature.asc Description: This is a digitally signed message part -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Wed, 2012-10-31 at 18:30 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Wed, 2012-10-31 at 18:15 +0100, Serge Hallyn wrote: Can you tell me the exact git tree and branch you are using? I'm using head. I'm not specifying a tree. ? I'm not sure what you mean - are you using git://github.com/lxc/lxc, or the tree on lxc.sf.net? IOW, I'm not using a branch in the tree. I'm using the main trunk. Created my tree with - git clone git://github.com/lxc/lxc So the former, not the later. The results you're getting don't make sense to me... Hoping I can find a simple answer. Me too. -serge Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! signature.asc Description: This is a digitally signed message part -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
Quoting Michael H. Warfield (m...@wittsend.com): On Mon, 2012-10-29 at 10:18 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): ... Yeah, I don't think I need to play a game like this anymore. I'd have to go back through some old old E-Mails to see why I did that before. I seem to recall we were playing with all sorts of bind mount options for some PRIVATE thing or another. It may not be necessary at all any longer. IAC, it's minor to switch it back. I seem to recall switching back and forth using bind mounts several times back when that got done that way. I may play with the pre-mount hook just for giggles and see how that might work as well. Any idea why I was experiencing the problem with the mount hook when trying to populate /dev? I know it wouldn't have The only idea I have is that perhaps your root is MS_SHARED by default? Can you post the script you were using and the container config? Another point on the curve... The documentation says that pre-mount takes place before the mount occurs and mount takes place after the mount occurs. Only problem is that pre-mount is not being recognized. I have serge@serge-ThinkPad-X130e:~$ cat /var/lib/lxc/premount #!/bin/bash echo 'hi there' /tmp/hw serge@serge-ThinkPad-X130e:~$ head -2 /var/lib/lxc/q4/config lxc.hook.pre-mount = /var/lib/lxc/premount lxc.network.type=veth serge@serge-ThinkPad-X130e:~$ sudo lxc-start -n q4 -d serge@serge-ThinkPad-X130e:~$ cat /tmp/hw hi there (This is using lxc 0.8.0~rc1-4ubuntu39 in ubuntu quantal) -serge -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): : I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it probably doesn't make much difference. Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev we should create the tty files. I need to fix that. Well... I'm not sure I understand what you mean by that. The /dev/pts/* entries do does exist in the host system. But the bind mount fails saying they do not exist. Not sure I understand what the problem is here but I would like them connected even if systemd doesn't start getty's on them. I've used them for other purposes in the past. Of course in your case since systemd isn't going to start getty's on them, you should not have the lxc.tty = 6 in your container config, which it looks like you still do? Actually, I've decided this is worthy of debugging and there may be other ways to start a getty (or something else) on that tty. It really should work. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! signature.asc Description: This is a digitally signed message part -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): : I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it probably doesn't make much difference. Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev we should create the tty files. I need to fix that. Well... I'm not sure I understand what you mean by that. The /dev/pts/* entries do does exist in the host system. But the bind mount fails saying they do not exist. Not sure I understand what the In Ubuntu, we use lxc.ttydir = lxc. That means the actual /dev/ttyN in the container is a symlink to /dev/lxc/ttyN (to allow package upgrades which insist on removing /dev/ttyN to succeed - they will fail if /dev/ttyN is mounted over). When /dev was pre-populated, /dev/ttyN existed. But when we are populating it, it does not. So before we try tomount /dev/pts/NN from the host onto /dev/ttyN in the container, we have to create a file to bind mount over. I didn't put that in the patch. Yet. problem is here but I would like them connected even if systemd doesn't start getty's on them. I've used them for other purposes in the past. Of course in your case since systemd isn't going to start getty's on them, you should not have the lxc.tty = 6 in your container config, which it looks like you still do? Actually, I've decided this is worthy of debugging and there may be other ways to start a getty (or something else) on that tty. It really should work. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Tue, 2012-10-30 at 19:35 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): : I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it probably doesn't make much difference. Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev we should create the tty files. I need to fix that. Well... I'm not sure I understand what you mean by that. The /dev/pts/* entries do does exist in the host system. But the bind mount fails saying they do not exist. Not sure I understand what the In Ubuntu, we use lxc.ttydir = lxc. That means the actual /dev/ttyN in the container is a symlink to /dev/lxc/ttyN (to allow package upgrades which insist on removing /dev/ttyN to succeed - they will fail if /dev/ttyN is mounted over). When /dev was pre-populated, /dev/ttyN existed. But when we are populating it, it does not. So before we try tomount /dev/pts/NN from the host onto /dev/ttyN in the container, we have to create a file to bind mount over. I didn't put that in the patch. Yet. Got it! You and I both did the same thing. I'm thinking from the view of Fedora and you're thinking from the view of Ubuntu. Got it. We'll get this right yet. :-)=) problem is here but I would like them connected even if systemd doesn't start getty's on them. I've used them for other purposes in the past. Of course in your case since systemd isn't going to start getty's on them, you should not have the lxc.tty = 6 in your container config, which it looks like you still do? Actually, I've decided this is worthy of debugging and there may be other ways to start a getty (or something else) on that tty. It really should work. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! signature.asc Description: This is a digitally signed message part -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Mon, 2012-10-29 at 10:18 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): ... Yeah, I don't think I need to play a game like this anymore. I'd have to go back through some old old E-Mails to see why I did that before. I seem to recall we were playing with all sorts of bind mount options for some PRIVATE thing or another. It may not be necessary at all any longer. IAC, it's minor to switch it back. I seem to recall switching back and forth using bind mounts several times back when that got done that way. I may play with the pre-mount hook just for giggles and see how that might work as well. Any idea why I was experiencing the problem with the mount hook when trying to populate /dev? I know it wouldn't have The only idea I have is that perhaps your root is MS_SHARED by default? Can you post the script you were using and the container config? Another point on the curve... The documentation says that pre-mount takes place before the mount occurs and mount takes place after the mount occurs. Only problem is that pre-mount is not being recognized. lxc-start 1351627853.032 ERRORlxc_confile - unknown key lxc.hook.pre-mount This is the same binaries from git that recognize lxc.hook.mount so I'm assuming the doco and the code don't match at this point. Even without my original bind mount, if I have a mount hook that does something in a newly mounted tmpfs directory, it doesn't show up in that directory it shows up in the parent directory as if it ran before the mounts took place. I could put the mount in the hook.mount script and then do it but it's seriously acting like the pre-mount hook isn't even there (parameter unknown) and the mount hook is running before the mounts are complete. Simple exerts from some test scripts doing, really, nothing but testing sequencing... Ok... Lets try this. I won't post entire configs but... For machine Alcove (my testbed)... -- lxc.tty = 6 lxc.pts = 64 lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=none/srv/lxc/private/Alcove/dev.tmp tmpfs defaults 0 0 lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 # lxc.hook.pre-mount = /var/lib/lxc/Alcove/pre-mount lxc.hook.mount = /var/lib/lxc/Alcove/mount lxc.mount.entry=shmfs /var/lib/lxc/private/Alcove/dev/shm tmpfs mode=0644 0 0 -- Now /var/lib/lxc/Alcove/mount: -- #!/bin/sh - touch /srv/lxc/private/Alcove/dev.tmp/mounted -- In that directory on the host fs I have this: [root@forest mhw]# touch /srv/lxc/private/Alcove/dev.tmp/no-mounted [root@forest mhw]# ls /srv/lxc/private/Alcove/dev.tmp/ no-mounted Now, when I start the container, the tmpfs should get mounted on /dev.tmp in the container (relative to the container rootfs) and should have the single file mounted in it while the parent file system back on the host should have the single file not-mounted in it. Let's see... lxc-start -n Alcove... In the container... [mhw@alcove ~]$ mount | grep tmpfs none on /dev type tmpfs (rw,relatime,seclabel,size=100k) none on /dev.tmp type tmpfs (rw,relatime,seclabel) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755) Looks like the mount took place. I have tmpfs on /dev.tmp [mhw@alcove ~]$ ls /dev.tmp/ [mhw@alcove ~]$ Opps... Where did the file end up? Let's look on the host... [mhw@forest ~]$ ls /srv/lxc/private/Alcove/dev.tmp/ mounted no-mounted Arg... Wrong answer. It ended up in the parent file system before tmpfs was mounted. But, the documentation says hook.mount runs after the mounts have completed. There's something wrong here or I am badly mistaken in my understanding... (Probably the later, I'll admit.) Regards, Mike worked because of the /dev/pts mount but I have more heartburn in that it looks like it ran too early and the mount on /dev had not even taken place at that time. I believe I can see why... You're doing the autodev populate prior to any of the mounts being performed, so that private root file system is not bound to the directory at that time. Drop that bind mount for the rootfs and this then worked like a charm: -- lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- I think that rootfs directory bind was an effort to more fully match the OpenVZ behavior but also trying to deal with some of the read-only problems were where having in the past with shutdowns. If it won't work, it won't work and I won't miss it. I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory -
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
Quoting Michael H. Warfield (m...@wittsend.com):
...
Yeah, I don't think I need to play a game like this anymore. I'd have
to go back through some old old E-Mails to see why I did that before. I
seem to recall we were playing with all sorts of bind mount options for
some PRIVATE thing or another. It may not be necessary at all any
longer. IAC, it's minor to switch it back. I seem to recall switching
back and forth using bind mounts several times back when that got done
that way.
I may play with the pre-mount hook just for giggles and see how that
might work as well. Any idea why I was experiencing the problem with
the mount hook when trying to populate /dev? I know it wouldn't have
The only idea I have is that perhaps your root is MS_SHARED by default?
Can you post the script you were using and the container config?
worked because of the /dev/pts mount but I have more heartburn in that
it looks like it ran too early and the mount on /dev had not even taken
place at that time.
I believe I can see why... You're doing the autodev populate prior to
any of the mounts being performed, so that private root file system is
not bound to the directory at that time.
Drop that bind mount for the rootfs and this then worked like a charm:
--
lxc.rootfs = /srv/lxc/private/Alcove
lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none
ro,bind 0 0
lxc.autodev = 1
--
I think that rootfs directory bind was an effort to more fully match the
OpenVZ behavior but also trying to deal with some of the read-only
problems were where having in the past with shutdowns. If it won't
work, it won't work and I won't miss it.
I did see some errors setting up that dev...
--
[root@forest mhw]# lxc-start -n Alcove
lxc-start: No such file or directory - failed to mount
'/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1'
lxc-start: No such file or directory - failed to mount
'/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2'
lxc-start: No such file or directory - failed to mount
'/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3'
lxc-start: No such file or directory - failed to mount
'/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4'
lxc-start: No such file or directory - failed to mount
'/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5'
lxc-start: No such file or directory - failed to mount
'/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6'
systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA
+SYSVINIT +LIBCRYPTSETUP; fedora)
Welcome to Fedora 17 (Beefy Miracle)!
--
Not sure what that's all about but, since systemd isn't going to start
getty's on the tty? interfaces anyways, it probably doesn't make much
difference.
Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev
we should create the tty files. I need to fix that.
Cool. Once again... Looks like we got some real progress here with
this one. I've still got more testing to do, undoing some of my changes
in the container itself and making sure it all still works.
Also looks like I can stop and restart one of these containers now
without the hung cgroup directory. I suspected it was some stray
devices behind that. This is good.
Of course in your case since systemd isn't going to start getty's on
them, you should not have the lxc.tty = 6 in your container config,
which it looks like you still do?
Yeah. I was taking it one step at a time. I wish they WOULD fire up
some getty's on those tty's since that basically makes lxc-console kinda
As I recall, you can specify gettys to start on any tty by creating a
magical symlink, something like
$ETC/getty.target.wants/getty\@tty{1,2,3,4,5,6}.service
useless and the one on /dev/console is kinda useless in disconnected
mode with the console redirected to a file. Maybe we need some what for
lxc-console to be able to grab that? I'll have to look deeper at
systemd and figure out if it can be parameterized or conditionalized in
some way. ITMT, I probably will just turn them off.
Many thanks!
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
--
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: /me erasing everything at this point and taking off the systemd crew, since this will have no relevance to them... Testing the hook feature out using git rev (finally got it built)... I added this line to my config... lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 lxc.hook.mount = /var/lib/lxc/Plover/mount In /var/lib/lxc/Plover/mount I have this: -- rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ -- (This is just testing out the concepts. If I understand this correctly, lxc.hook.pre-mount runs BEFORE the mounting takes place and lxc.hook.mount takes place after the mount. Problem is, the result of that rsync is not showing up in the mounted tmpfs file system but is showing up in the underlying parent file system as if it were run pre-mount. Something not right here... I changed it to lxc.hook.start = /srv/lxc/mount (where I put the script in the container) which then works but that then requires the template and the command to be in the container. Suboptimal to say the least. But it gives me a way to test this tmpfs thing out. I also noticed that the .start hook runs, it appears, after caps are dropped and I see a lot of bitching about mknod on certain devices. I had to thrown an exit 0 into that script so it would continue in spite of the errors but, now, I can refine my template based on what it could create. Crap. I've got a catch-22 here... This is going to take some work. Hey, I've got a rather minimal patch (appended below) to add the support for mounting and populating a minimal /dev working. (A few hours were wasted due to my not knowing that upstart was going to issue mounted-dev even though /dev was mounted before upstart started - and the mounted-dev hook deletes and recreates all consoles. GAH) I am happy to report that, after manually editing my git head branch to patch in the failed hunks, I was able to build it and test it and my Fedora 17 systemd based container fired right up after adding the lxc.autodev = 1 parameter to the config file. Yeah I did run into one gotcha, but one I can live with. I had been bind mounting the private root file system to another directory and then using that as the rootfs like this: -- lxc.rootfs = /srv/lxc/rootfs lxc.mount.entry=/srv/lxc/private/Alcove /srv/lxc/rootfs none bind.shared 0 0 lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- This did not work and I got the startup error that it can not mount to /dev because it doesn't exist. I believe I can see why... You're doing the autodev populate prior to any of the mounts being performed, so that private root file system is not bound to the directory at that time. Drop that bind mount for the rootfs and this then worked like a charm: -- lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- I think that rootfs directory bind was an effort to more fully match the OpenVZ behavior but also trying to deal with some of the read-only problems were where having in the past with shutdowns. If it won't work, it won't work and I won't miss it. I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it probably doesn't make much difference. Regards, Mike Yes, we can create the /dev directory with tmpfs from a template. Problem is that /dev/pts does not exist at the time we need to mount the devpts on /dev/pts for the pty's so that hurls chunks and dies. We can't create the /dev/ directory contents prior to mounting in the pre-mount hook because we won't have tmpfs in place at the time. We have to get
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: /me erasing everything at this point and taking off the systemd crew, since this will have no relevance to them... Testing the hook feature out using git rev (finally got it built)... I added this line to my config... lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 lxc.hook.mount = /var/lib/lxc/Plover/mount In /var/lib/lxc/Plover/mount I have this: -- rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ -- (This is just testing out the concepts. If I understand this correctly, lxc.hook.pre-mount runs BEFORE the mounting takes place and lxc.hook.mount takes place after the mount. Problem is, the result of that rsync is not showing up in the mounted tmpfs file system but is showing up in the underlying parent file system as if it were run pre-mount. Something not right here... I changed it to lxc.hook.start = /srv/lxc/mount (where I put the script in the container) which then works but that then requires the template and the command to be in the container. Suboptimal to say the least. But it gives me a way to test this tmpfs thing out. I also noticed that the .start hook runs, it appears, after caps are dropped and I see a lot of bitching about mknod on certain devices. I had to thrown an exit 0 into that script so it would continue in spite of the errors but, now, I can refine my template based on what it could create. Crap. I've got a catch-22 here... This is going to take some work. Hey, I've got a rather minimal patch (appended below) to add the support for mounting and populating a minimal /dev working. (A few hours were wasted due to my not knowing that upstart was going to issue mounted-dev even though /dev was mounted before upstart started - and the mounted-dev hook deletes and recreates all consoles. GAH) I am happy to report that, after manually editing my git head branch to Sorry, it was against the ubuntu quantal package. I've been in the air without onboard wifi, so working with what i had at hand. patch in the failed hunks, I was able to build it and test it and my Fedora 17 systemd based container fired right up after adding the lxc.autodev = 1 parameter to the config file. Yeah I did run into one gotcha, but one I can live with. I had been bind mounting the private root file system to another directory and then using that as the rootfs like this: -- lxc.rootfs = /srv/lxc/rootfs lxc.mount.entry=/srv/lxc/private/Alcove /srv/lxc/rootfs none bind.shared 0 0 lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- This did not work and I got the startup error that it can not mount to /dev because it doesn't exist. Hm, yeah. If you do need to play a game like this, you might be best off using a pre-mount hook for that. I believe I can see why... You're doing the autodev populate prior to any of the mounts being performed, so that private root file system is not bound to the directory at that time. Drop that bind mount for the rootfs and this then worked like a charm: -- lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- I think that rootfs directory bind was an effort to more fully match the OpenVZ behavior but also trying to deal with some of the read-only problems were where having in the past with shutdowns. If it won't work, it won't work and I won't miss it. I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it
Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: : I've got a rather minimal patch (appended below) to add the support for mounting and populating a minimal /dev working. (A few hours were wasted due to my not knowing that upstart was going to issue mounted-dev even though /dev was mounted before upstart started - and the mounted-dev hook deletes and recreates all consoles. GAH) I am happy to report that, after manually editing my git head branch to Sorry, it was against the ubuntu quantal package. I've been in the air without onboard wifi, so working with what i had at hand. Oh, I figured it was a package mismatch. Wasn't too terribly difficult to patch those hunks in and kick out a diff against git. patch in the failed hunks, I was able to build it and test it and my Fedora 17 systemd based container fired right up after adding the lxc.autodev = 1 parameter to the config file. Yeah I did run into one gotcha, but one I can live with. I had been bind mounting the private root file system to another directory and then using that as the rootfs like this: -- lxc.rootfs = /srv/lxc/rootfs lxc.mount.entry=/srv/lxc/private/Alcove /srv/lxc/rootfs none bind.shared 0 0 lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- This did not work and I got the startup error that it can not mount to /dev because it doesn't exist. Hm, yeah. If you do need to play a game like this, you might be best off using a pre-mount hook for that. Yeah, I don't think I need to play a game like this anymore. I'd have to go back through some old old E-Mails to see why I did that before. I seem to recall we were playing with all sorts of bind mount options for some PRIVATE thing or another. It may not be necessary at all any longer. IAC, it's minor to switch it back. I seem to recall switching back and forth using bind mounts several times back when that got done that way. I may play with the pre-mount hook just for giggles and see how that might work as well. Any idea why I was experiencing the problem with the mount hook when trying to populate /dev? I know it wouldn't have worked because of the /dev/pts mount but I have more heartburn in that it looks like it ran too early and the mount on /dev had not even taken place at that time. I believe I can see why... You're doing the autodev populate prior to any of the mounts being performed, so that private root file system is not bound to the directory at that time. Drop that bind mount for the rootfs and this then worked like a charm: -- lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- I think that rootfs directory bind was an effort to more fully match the OpenVZ behavior but also trying to deal with some of the read-only problems were where having in the past with shutdowns. If it won't work, it won't work and I won't miss it. I did see some errors setting up that dev... -- [root@forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'-'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'-'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'-'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'-'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'-'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'-'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it probably doesn't make much difference. Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev we should create the tty files. I need to fix that. Cool. Once again... Looks like we got some real progress here with this one. I've still got more testing to do, undoing some of my changes in the container itself and making sure it all still works. Also looks like I can stop and restart one of these containers now without the hung cgroup directory. I suspected it was some stray devices behind that. This is good. Of course in your case since systemd isn't going to start getty's on them, you should not have the lxc.tty = 6 in your container config, which it looks like you still do? Yeah. I was taking it one step at a time. I wish they WOULD fire up
