Date: Fri, 18 Nov 2011 11:11:46 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: David Wolfskill <david@catwhisker.org> Cc: freebsd-ports@freebsd.org, ehaupt@freebsd.org Subject: Re: Support for running xterm within a jail? Message-ID: <20111118091146.GZ50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111117194412.GP1706@albert.catwhisker.org> References: <20111117194412.GP1706@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--GKlHQQh5GQ4Mg0aN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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). >=20 > (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.) >=20 > 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. >=20 > There's even a bit to effectively ignore ENOENT -- if __CYGWIN__ is > defined. >=20 > But that's not our case -- and we don't want to be defining __CYGWIN__ > when we're building xterm for FreeBSD. >=20 > 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). >=20 > 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. >=20 > 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? >=20 > 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? >=20 > (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. --GKlHQQh5GQ4Mg0aN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7GIVIACgkQC3+MBN1Mb4jJCACeKyZbTS4RktMjn2pZ+FckiPap wRUAnj5chFlE9dFgQPLvF62q80WDOy2d =HGKP -----END PGP SIGNATURE----- --GKlHQQh5GQ4Mg0aN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111118091146.GZ50300>