Re: [libvirt] [PATCH 1/2] Fix occasional container creation failure due to misuse of grantpt
Quoting Eric Blake (ebl...@redhat.com): ... of /dev/pts, then passing that fd back to the parent; the alternative solution would be to ditch glibc interfaces and do the raw ioctl calls on the master pty ourselves. Since lxc is already Linux-specific, I think that I would favor this approach as being simpler (that is, completely ditch virFileOpenTtyAt, and teach lxc to just make the raw ioctl calls instead of using grantpt and unlockpt, all without forking or passing fds across a socket). Serge, is this something you can attempt, or should I look into it more? Hey Eric, yup, if it's acceptable to you I think that's the better, simpler approach. I'll send out a new patch. thanks, -serge -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] Fix occasional container creation failure due to misuse of grantpt
On Wed, Oct 12, 2011 at 09:31:28PM -0500, Serge E. Hallyn wrote: glibc's grantpt and ptsname cannot be used on a fd for a pty not in /dev/pts. The lxc controller tries to do just that. So if you try to start a container on a system where /dev/pts/0 is not available, it will fail. You can make this happen by opening a terminal on /dev/pts/0, and doing 'sleep 2h disown; exit'. To fix this, I call the virFileOpenTtyAt() from a forked task in a new mount ns, and first mount the container's /dev/pts onto /dev/pts. (Then the opened fd must be passed back to the lxc driver). Another solution would be to just do it all by hand without grantpt and ptsname. GNULIB already has a 'grantpt' implementation for MinGW, OpenBSD and OS-X. So I wonder if they would like to fix the broken Linux glibc version too ? Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] Fix occasional container creation failure due to misuse of grantpt
On 10/12/2011 08:31 PM, Serge E. Hallyn wrote:
glibc's grantpt and ptsname cannot be used on a fd for a pty not in
/dev/pts. The lxc controller tries to do just that. So if you try to
start a container on a system where /dev/pts/0 is not available, it
will fail. You can make this happen by opening a terminal on
/dev/pts/0, and doing 'sleep 2h disown; exit'. To fix this, I call
the virFileOpenTtyAt() from a forked task in a new mount ns, and first
mount the container's /dev/pts onto /dev/pts. (Then the opened fd must
be passed back to the lxc driver). Another solution would be to just
do it all by hand without grantpt and ptsname.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/863629
Signed-off-by: Serge Hallynserge.hal...@canonical.com
---
src/lxc/lxc_controller.c | 117 --
1 files changed, 112 insertions(+), 5 deletions(-)
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 51488e7..1a56e0c 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -780,6 +780,113 @@ static int lxcSetPersonality(virDomainDefPtr def)
# define MS_SLAVE (119)
#endif
+static int send_pty(int sock, int *pty)
+{
+struct iovec vector;
+struct msghdr msg;
+struct cmsghdr * cmsg;
+int ret;
+
Yuck. Why not just use gnulib's sendfd/recvfd interfaces, and greatly
shrink the size of this patch? We're already using those functions
elsewhere, for much more compact fd passing.
+if (VIR_ALLOC_N(*path, PATH_MAX) 0) {
+virReportSystemError(errno, %s,
+_(Failed to allocate space for ptyname));
+return -ENOMEM;
+}
+//snprintf(*path, PATH_MAX, %s/0, devpts);
Also, looks like you left some debug stuff behind.
Have you filed a bug against glibc's grantpt?
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] Fix occasional container creation failure due to misuse of grantpt
On 10/13/2011 09:47 AM, Eric Blake wrote: On 10/12/2011 08:31 PM, Serge E. Hallyn wrote: glibc's grantpt and ptsname cannot be used on a fd for a pty not in /dev/pts. The lxc controller tries to do just that. So if you try to start a container on a system where /dev/pts/0 is not available, it will fail. You can make this happen by opening a terminal on /dev/pts/0, and doing 'sleep 2h disown; exit'. To fix this, I call the virFileOpenTtyAt() from a forked task in a new mount ns, and first mount the container's /dev/pts onto /dev/pts. (Then the opened fd must be passed back to the lxc driver). Another solution would be to just do it all by hand without grantpt and ptsname. Have you filed a bug against glibc's grantpt? I should have read your URL, which points to http://www.cygwin.com/ml/libc-alpha/2011-10/msg8.html. My conclusions from that thread are: We are outside the bounds of POSIX the moment we create a private pts mount point not located at /dev/pts. Gnulib can't fix the situation for us (gnulib grantpt is only useful in the context of an application trying to comply with existing POSIX rules, and cloning/unsharing namespaces to create a private pts is not in scope for gnulib). So I don't see that anything is worth reporting to gnulib after all. Now, after reading more of the code, I see that src/util/util.c exports virFileOpenTty(), which is hard-coded to opening /dev/ptmx (when it should _really_ be using posix_openpt to be portable to all platforms). It also provides (but we forgot to export in libvirt_private.syms) virFileOpenTtyAt, which is Linux-specific in trying to accommodate alternate mount points for the pts system. Currently, the only clients for these two functions is lxc; although virFileOpenTty() might be useful to other clients that aren't doing Linux-specific container games with the file system. So the problem at hand is that as soon as you have a private pts, glibc doesn't interact well with it. That is, virFileOpenTtyAt() is worthless in that situation. Serge's patch provides a replacement for _just_ the private pts situation, which uses glibc by forking and bind-mounting the private pts back into the glibc expectations of /dev/pts, then passing that fd back to the parent; the alternative solution would be to ditch glibc interfaces and do the raw ioctl calls on the master pty ourselves. Since lxc is already Linux-specific, I think that I would favor this approach as being simpler (that is, completely ditch virFileOpenTtyAt, and teach lxc to just make the raw ioctl calls instead of using grantpt and unlockpt, all without forking or passing fds across a socket). Serge, is this something you can attempt, or should I look into it more? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
