Weird interaction between chroot jail and shell-mode

Weird interaction between chroot jail and shell-mode

[Sean McAfee]

This is probably the most perplexing Emacs issue I've ever
encountered...

I've been trying to build the debian "apt" package in a shell-mode bash
shell, inside of which I've entered a chroot jail.  The build process
(initiated with the command "dpkg-buildpackage") would reach a point
where it executes the command:

  po4a --previous --no-backups po4a.conf

...whereupon the command hangs, consuming 100% of the CPU until I kill
it.

A co-worker had no trouble building the package in an ordinary terminal
window on his own machine, and, unable to find any reason for my issue,
suggested that Emacs might be to blame.  I was dubious, to say the
least, but to humor him I repeated the process in my own terminal
window.  To my astonishment, the package didn't get hung up on the po4a
command, but ran to completion successfully.

I tried building the package inside a terminal emulator window inside
Emacs.  It built.  I tried again using eshell, which I ordinarily never
use.  The build got hung up at the same point as originally, with the
additional delightfulness that I couldn't interrupt the hung command
with C-c C-c.  Finally, I tried building the package in a shell-mode
shell again, but without entering the chroot jail.  It built.  WTF.

I tried dumping my environment variables in the jail in shell-mode and
term-mode and comparing them.  The only differences were in OLDPWD,
LSCOLORS, and TERM ("dumb" in shell-mode, "vt100" in term-mode).  I
repeated the build in shell-mode after setting TERM to vt100, but it
still got hung.

I am utterly perplexed.  Does anyone have any possible explanation for
the behavior I'm seeing?  How in the world can any command produce
different behavior when run inside vs. outside of a chroot jail, but
only when run from a bash shell which itself is running inside a
shell-mode buffer?

Re: Weird interaction between chroot jail and shell-mode

[Sean McAfee]

Sean McAfee <eefacm@gmail.com> writes:
> This is probably the most perplexing Emacs issue I've ever
> encountered...
>
> I've been trying to build the debian "apt" package in a shell-mode bash
> shell, inside of which I've entered a chroot jail.  The build process
> (initiated with the command "dpkg-buildpackage") would reach a point
> where it executes the command:
>
>   po4a --previous --no-backups po4a.conf
>
> ...whereupon the command hangs, consuming 100% of the CPU until I kill
> it.

Well, I guess this is pretty much solved...

On investigating the po4a command, which is a Perl program, I found that
the hanging was occuring in a call to a function called "wrap_msg."
Ultimately this routine uses the terminal size reported by the
GetTerminalSize function in the standard Term::ReadKey module, which in
a shell-mode shell explicitly reports a screen width and height of zero.
Small wonder that a trusting wrapping function would get stuck in an
infinite loop...

But then, why would I still be able to build successfully in a
shell-mode shell outside of a chroot jail?  Because wrap_msg will check
the COLUMNS environment variable, and use that if it's set instead of
calling Term::ReadKey::GetTerminalSize.  Outside of the chroot, my
COLUMNS variable is set correctly.  Inside, however it is that the root
user's shell environment gets set up, COLUMNS is set as a shell
variable, but it is not exported as an environment variable.  Adding an
"export COLUMNS" to the end of the chrooted root user's .bashrc file
fixed the hanging problem.

Ultimately, this would seem to be Term::ReadKey's fault.  It advertises
a way to indicate that the terminal size could not be
determined--returning an empty list--but instead it returns nonsensical
screen dimensions of 0x0.

Re: Weird interaction between chroot jail and shell-mode

[Ilya Zakharevich]

On 2010-11-01, Sean McAfee <eefacm@gmail.com> wrote:

> the hanging was occuring in a call to a function called "wrap_msg."
> Ultimately this routine uses the terminal size reported by the
> GetTerminalSize function in the standard Term::ReadKey module, which in
> a shell-mode shell explicitly reports a screen width and height of zero.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Ultimately, this would seem to be Term::ReadKey's fault.  It advertises
> a way to indicate that the terminal size could not be
> determined--returning an empty list--but instead it returns nonsensical
> screen dimensions of 0x0.

How do you interpret this as a fault of Term::ReadKey?  It got an
"explicit report".  Why should it indicate that it did not?

Yours,
Ilya

P.S.  Of course, sometimes it is more useful to cheat than to
      "stupidly follow the specification" in the corner cases.  But
      one needs to have a more-or-less clear picture of possible
      consequences.  As the simplest example, does wrap_msg() handle
      the empty list return from GetTerminalSize()?