On Sat January 14 2006 11:20, Benedikt Boehm wrote:
> On Saturday 14 January 2006 17:34, Michael S. Zick wrote:
> > Using: strace -o screen.txt -e trace=file screen (from within an xterm)...
> >
> > These are the system calls (in the guest) that you have to make succeed
> > from the host that is running udev (the pts/1 is because the xterm is using
> > pts/0):
> >
> > - - - -
> > readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 10
> > - - - -
> > readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
> > stat64("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...})
> > = 0 open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3
> > - - - -
> >
> > So a simple hardlink might not work, but having a rule script that also (on
> > the host) makes the correct node in /<vservers>/<guestroot>/dev/pts/*
> > should work.
>
> you're not supposed to make device nodes in /dev/pts, because it is a dynamic
> filesystem showing allocated pseudo terminals... [1]
>
> >
> > Note that it is the stat64 ... st_rdev=makedev(136, 1) that is the call to
> > the udev system, in your case, triggered on the guest and but directed at
> > the host.
> >
> > So the question remains: Which VServer (by host path) and which xid?
> >
> > It can't be the /proc/self/<anything> read by the script, since that is
> > running on the host - not in the guest context that triggered the request
> > for a pts.
> >
> > Still scratching my head over this question - it might require a pre-loaded
> > *.so in the guest context to trap these trigger events and proxy them to
> > the udev system running in the host context (with the additional info
> > required).
> >
> > I just hope someone can suggest an easier way.
> > A good starting point would be to repeat my tests, since they may have
> > cockpit errors.
>
> Well, prefering fixes and not workarounds (as stated previously ;) i'd rather
> tend to create the necessary files in /dev/pts (inside the guest) by
> allocating a pseudo terminal after migrating the vserver process.. trying it
> out right now, and will report any issue back here..
>
The main issue is that the /dev/pts is a kernel provided, virtual filesystem
that tracks which of the 255 pts are in use.
However you do it, you have to run through the kernel in context 0 so that its
record keeping is correct.
Otherwise, you might end up using pts/0 in all of the guests while the kernel
records that pts/0, pts/1, pts/2 ... are in use.
I am pretty sure that the kernel will believe any major/minor number a device
special node carries - so even though the kernel is assigning a new /dev/pts/16
to the most recent request - hand creating a /vserver/vps16/dev/pts/16 should
work since it has the correct major/minor. Programs within the guest (such as
login) that check for a link outside of /dev/* will only see the guest's view
of /dev/pts/16.
I am not suggesting that one should modify /dev/pts/* - only the
/vserver/vps16/dev/pts/16 path. The trick is keeping it in lock-step with the
kernel's virtual filesystem.
Mike
> [1] http://www.nsa.gov/selinux/papers/slinux/node60.html
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Sat Jan 14 17:49:15 2006