Skip site navigation (1)Skip section navigation (2)
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>