Re: Support for running xterm within a jail?
On Thu, Nov 17, 2011 at 11:44:12AM -0800, David Wolfskill wrote: At $WORK, we have recently been reminded that xterm doesn't cope all that well with being invoked in an environment that returns ENOENT on xterm's attempt to open /dev/tty (in main.c). (The environment in question is a jailed 32-bit FreeBSD running on a FreeBSD/amd64 host. Developers need to build in the jail; apparently they also want to run things like emacs in the jails.) In looking at the xterm sources, I found that there's some code (near main.c:3311 - 3329) to take evasive action if the attempt to open /dev/tty fails. There's even a bit to effectively ignore ENOENT -- if __CYGWIN__ is defined. But that's not our case -- and we don't want to be defining __CYGWIN__ when we're building xterm for FreeBSD. Given that FreeBSD (with devfs) *can* return ENOENT to the attempt to open /dev/tty, it isn't clear to me why that aprticular error condition isn't ignored unconditionally (in a FreeBSD environment, at least). Accordingly, I cobbled up a patch (attached), and a colleague has verified that it avoids the issue we were encountering: it allows xterm to run in the jail. Do you think the xterm folks would be receptive to either making the ignore ENOENT unconditional or conditioning it on (say) __CYGWIN_ being defined or __FREEBSD__ being defined? Failing that (or in the mean time) would you be receptive to a patch to the FreeBSD xterm port to patch xterm in a way similar to the attached patch? (I realize we're approaching 9.0-RELEASE; I'm not asking anyone to make changes before that release date.) I am sure that the issue is a misconfiguration of the jail or attempt to start xterm from the process that has no control terminal. For jail misconfiguration, I mean either failure to properly mount devfs into the jail /dev, or a rule that hides /dev/tty from the jail. I use very similar configuration (32bit stable/8 jail on amd64 stable/9 kernel) and have no issues starting xterm. That said, you should diagnose the issue further, otherwise I think the patch is unneccessary. pgpl06o1Li6O7.pgp Description: PGP signature
Re: Support for running xterm within a jail?
On Fri, Nov 18, 2011 at 11:11:46AM +0200, Kostik Belousov wrote: ... I am sure that the issue is a misconfiguration of the jail or attempt to start xterm from the process that has no control terminal. For jail misconfiguration, I mean either failure to properly mount devfs into the jail /dev, or a rule that hides /dev/tty from the jail. I use very similar configuration (32bit stable/8 jail on amd64 stable/9 kernel) and have no issues starting xterm. That said, you should diagnose the issue further, otherwise I think the patch is unneccessary. I appreciate that, but admit that I'm not especially familiar with working with jails. i also admit that the use case is one that strikes me as perverse, in that I would expect someone to run an xterm locally. In the case in question, the folks encountering the problem do not have local X servers; they use MS Windows (with which I am almost completely unfamiliar -- and in which I have no interest) on their desktops. As I type, I am logged in to my desktop machine at work remotely (from home, in another xterm). From that xterm, I can run (e.g.): dwolf-bsd(8.2-S)[10] ssh -Yfn dwolf-bsd xterm -T testing and get a new xterm up, running on my desktop with DISPLAY set to a value that will allow me to run other X clients from it. This is the functionality that is wanted. If, instead, I do something similar to one of our older build machines: dwolf-bsd(8.2-S)[11] ssh -Yfn dwolf.svl-lb xterm -T testing I get a similar result -- an xterm running on the build machine with DISPLAY set so I could run other X clients (e.g., emacs). If I do the same for one of the jails: dwolf-bsd(8.2-S)[12] ssh -Yfn svl-jail xterm -T testing dwolf-bsd(8.2-S)[13] xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty If I use ssh login to the jail: dwolf-bsd(8.2-S)[13] ssh -Y svl-jail ... svl-jail(7.1-R)[1] I can manually fire off xterm because /dev/tty exists and I am already running an X server locally: svl-jail(7.1-R)[1] ls -lTio /dev/tty 135 crw--w 1 dwolf tty - 0, 135 Nov 18 05:59:58 2011 /dev/tty But if I terminate that connection, then try to perform that ls command (as the only thing I want ssh to do for me), that only works if I include the -t on the ssh invocation. So if I try adding -t when I try to start the remote xterm, I see: dwolf-bsd(8.2-S)[17] ssh -Ytfn svl-jail xterm -T testing Pseudo-terminal will not be allocated because stdin is not a terminal. dwolf-bsd(8.2-S)[18] xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty So I think it's apparent that we don't have a case where /dev/tty is never available, but I don't know how to make it show up for the intended use case. And there already exists code in xterm to ignore the ENOENT case for CygWin, so it seems that there really isn't much of a reason to treat ENOENT on /dev/tty as a fatal error for xterm invocation. Further, applying the patch in question does provide the desired functionality. If you (or anyone else) could provide some clues as to where to direct my attention, that would be wonderful. (In the mean time, upstream xterm developer has agreed to make the change for xterm-277, and ehaupt@ has updated the x11/xterm port to include the patch, pending xterm-277.) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp3eGqUU8zOB.pgp Description: PGP signature
Re: Support for running xterm within a jail?
On Fri, Nov 18, 2011 at 06:13:20AM -0800, David Wolfskill wrote: On Fri, Nov 18, 2011 at 11:11:46AM +0200, Kostik Belousov wrote: ... I am sure that the issue is a misconfiguration of the jail or attempt to start xterm from the process that has no control terminal. For jail misconfiguration, I mean either failure to properly mount devfs into the jail /dev, or a rule that hides /dev/tty from the jail. I use very similar configuration (32bit stable/8 jail on amd64 stable/9 kernel) and have no issues starting xterm. That said, you should diagnose the issue further, otherwise I think the patch is unneccessary. I appreciate that, but admit that I'm not especially familiar with working with jails. i also admit that the use case is one that strikes me as perverse, in that I would expect someone to run an xterm locally. In the case in question, the folks encountering the problem do not have local X servers; they use MS Windows (with which I am almost completely unfamiliar -- and in which I have no interest) on their desktops. As I type, I am logged in to my desktop machine at work remotely (from home, in another xterm). From that xterm, I can run (e.g.): dwolf-bsd(8.2-S)[10] ssh -Yfn dwolf-bsd xterm -T testing and get a new xterm up, running on my desktop with DISPLAY set to a value that will allow me to run other X clients from it. This is the functionality that is wanted. If, instead, I do something similar to one of our older build machines: dwolf-bsd(8.2-S)[11] ssh -Yfn dwolf.svl-lb xterm -T testing I get a similar result -- an xterm running on the build machine with DISPLAY set so I could run other X clients (e.g., emacs). If I do the same for one of the jails: dwolf-bsd(8.2-S)[12] ssh -Yfn svl-jail xterm -T testing dwolf-bsd(8.2-S)[13] xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty If I use ssh login to the jail: dwolf-bsd(8.2-S)[13] ssh -Y svl-jail ... svl-jail(7.1-R)[1] I can manually fire off xterm because /dev/tty exists and I am already running an X server locally: svl-jail(7.1-R)[1] ls -lTio /dev/tty 135 crw--w 1 dwolf tty - 0, 135 Nov 18 05:59:58 2011 /dev/tty But if I terminate that connection, then try to perform that ls command (as the only thing I want ssh to do for me), that only works if I include the -t on the ssh invocation. So if I try adding -t when I try to start the remote xterm, I see: dwolf-bsd(8.2-S)[17] ssh -Ytfn svl-jail xterm -T testing Pseudo-terminal will not be allocated because stdin is not a terminal. dwolf-bsd(8.2-S)[18] xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty So I think it's apparent that we don't have a case where /dev/tty is never available, but I don't know how to make it show up for the intended use case. The ssh is explicitely saying you what is going on. Did you note the 'Pseudo-terminal will not be allocated because stdin is not a terminal.' line ? It telling that the control terminal will not be allocated. As a consequence, /dev/tty cannot be opened. This has nothing to do with jail. % ssh -Ytfn localhost tty Pseudo-terminal will not be allocated because stdin is not a terminal. not a tty % And there already exists code in xterm to ignore the ENOENT case for CygWin, so it seems that there really isn't much of a reason to treat ENOENT on /dev/tty as a fatal error for xterm invocation. Further, applying the patch in question does provide the desired functionality. If you (or anyone else) could provide some clues as to where to direct my attention, that would be wonderful. (In the mean time, upstream xterm developer has agreed to make the change for xterm-277, and ehaupt@ has updated the x11/xterm port to include the patch, pending xterm-277.) Peace, david -- David H. Wolfskillda...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpSzmiKjyXvV.pgp Description: PGP signature
