On Sun, 16 Apr 2000, Keresztfalvi Gabor wrote:
> On Sat, 15 Apr 2000, Eric J. Schwertfeger wrote:
> > Broken as in if you connect to lshd, it goes through host and user
> > authentication as normal, then lsh abruptly terminates. Propper debugging
> > info tomorrow, but for now, here's the only thing that looks unusual
> >
> > do_spawn_shell: Child process
> > do_exec_shell: Setting up environment.
> > do_exec_shell: Environment:
> > 'TERM'
> > 'K'
> > ''
> > '\'
> > Child 60125 killed by signal 11.
> Hmmm. Seems familiar... Are you running the _server_ with --debug?
> (probably yes, otherway you wouldn't get this message ;) Is it
> working without --debug? If this is the case, then check Niels' letter
> about a similar problem. (There was a patch for that, involving a call to
> debug() in unix_user.c).
I'm flabbergasted. I was aware of that patch, but hadn't tracked it down,
since the reason I had run with --debug was because it was dying without
it, and I wanted to find out why. But, i threw in that patch to see what
the debug output looked like. And the connection worked. I then stopped
and restarted lshd without --debug. And it still works. Thank you.
Is it possible that that bug might affect lshd even without the --debug
flag? it looks like debug is called regardless of the debug state.
At this point, the only quirk left before I'm happy calling this 1.0
(not that I have any say in this though :-) that I see is the tendancy on
FreeBSD 3.X for lsh to emit a ton of 0x07 characters when it exits. Or at
least that is the perceived behavior, it could be some strange
interaction [confirmed later on, only happens with one shell]. Doesn't
happen with FreeBSD 4.0 [not true, as noted later].
I can demonstrate it with the following commands on one of my 3.3 boxes.
(not currently using bash as my login shell, and haven't updated the
prompt, that's why it looks funny)
[\h:\u]\w> script
[\h:\u]\w> lsh localhost
(enter password)
[\h:\u]\w> exit
(beeping starts)
[\h:\u]\w> exit
(beeping ends)
and in the typescript file, I find:
000000d0 3a 5c 75 5d 5c 77 3e 20 65 78 69 74 5b 5c 68 3a |:\u]\w> exit[\h:|
000000e0 5c 75 5d 5c 77 3e 20 07 07 07 07 07 07 07 07 07 |\u]\w> .........|
000000f0 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 |................|
*
000026b0 07 07 07 07 07 65 07 07 07 07 07 07 07 07 07 07 |.....e..........|
000026c0 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 |................|
*
000027c0 07 07 07 07 07 78 07 07 07 07 07 07 07 07 07 07 |.....x..........|
000027d0 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 |................|
*
00002c00 69 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 |i...............|
00002c10 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 |................|
*
000040c0 07 07 74 07 07 07 07 07 07 07 07 07 07 07 07 07 |..t.............|
000040d0 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 |................|
*
000046b0 07 07 07 07 07 07 07 0d 0d 0a 0a 53 63 72 69 70 |...........Scrip|
000046c0 74 20 64 6f 6e 65 20 6f 6e 20 53 75 6e 20 41 70 |t done on Sun Ap|
000046d0 72 20 31 36 20 30 39 3a 35 34 3a 32 39 20 32 30 |r 16 09:54:29 20|
000046e0 30 30 0a |00.|
Examining this closely, I suspect that this is some kind of strange
interaction, rather than lsh by itself, since the 07s all appear after the
next shell prompt, and the letters e, x, i, and t (the second exit
command) are interspersed throughout the 07s. If lsh were spitting them
out, I'm pretty sure the exit would come after all the 07s.
As a quick test (since typing the last paragraph), I reinstalled bash
(2.0.3), set that as my default shell, ran the test, and got no beeps.
And now that I take a closer look, bash is my default shell on the 4.0
box, and if I go back to using /bin/sh, I get the beeping there.
(testing other shells; csh, tcsh, zsh, pdksh) Hmm... Only happens with
FreeBSD's /bin/sh, which is based on ash (has most of the features of
bash).
