[Bug 863629] Re: libvirt-lxc: virFileOpenTtyAt can't be called on /some/other/dev/pts
Scott Moser
smoser at canonical.com
Tue Oct 11 15:29:56 UTC 2011
I now know how I I was hitting this.
On my local system, I would log, open a terminal and and then run a bip proxy with:
ssh -o ControlPath=none -C -L 7778:localhost:7778 -f -N ${HOST}
I can replicate that same behavior by ssh'ing to a system, then doing:
sleep 30m & disown; exit
After that, 'sleep 30m' will be alive and holding the /dev/pts/0 so nothing will get that any more, but the entry is deleted.
I couldn't seem to get that to work through ssh running the command ie, the following kills the sleep and frees the /dev/pts/0:
ssh $HOST -t 'sleep 30m & disown; exit 0;'
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/863629
Title:
libvirt-lxc: virFileOpenTtyAt can't be called on /some/other/dev/pts
Status in “libvirt” package in Ubuntu:
Confirmed
Bug description:
lxcControllerRun() is calling virFileOpenTtyAt() with a slave opened
on /the/container/chroot/dev/pts. While it is not documented in the
manpages, glibc's grantpt does a first check (ensuring that the passed
in fd is a pty slave) with '/dev/pts' as the hardcoded path, appending
the pty#.
lxcControllerRun always calls this on the first slave opened after
creating the new /dev/pts, so grantpt is always checking /dev/pts/0.
Therefore, if your host does not have /dev/pts/0 (easy to reproduce
using screen), then grantpt will fail, and the container creation will
subsequently also fail.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/863629/+subscriptions
More information about the Ubuntu-sponsors
mailing list