On Friday 08 August 2008 02:58, Choi, Ben S wrote:
> Hi -
>
> I am using busybox-1.10.2 for our embedded application and noticed
> something peculiar about how the shell behaves after the application
> terminates. Specifically, I'm noticing that:
>
> 1. If there is no signal handler in the application, a <CNTRL>-C
> will not only terminate the application, but it appears that it
> propagates to the shell and kills not only the shell, but also the
> telnet session that is hosting the shell, which results in a telnet
> disconnect.
This should not happen. When ash runs a pipe (a "cmd1 | cmd2 | cmd3"
construct, including the degenerate case when there is only cmd1),
it creates a new process group, and puts this process group into
foreground (in other words, it sets terminal's foreground
process group ID to the pgid of this group). I think it happens here:
/* Called after fork(), in child */
static void
forkchild(struct job *jp, /*union node *n,*/ int mode)
{
int oldlvl;
TRACE(("Child shell %d\n", getpid()));
oldlvl = shlvl;
shlvl++;
closescript();
clear_traps();
#if JOBS
/* do job control only in root shell */
doing_jobctl = 0;
if (mode != FORK_NOJOB && jp->jobctl && !oldlvl) {
pid_t pgrp;
if (jp->nprocs == 0)
pgrp = getpid();
else
pgrp = jp->ps[0].pid;
/* This can fail because we are doing it in the parent also */
(void)setpgid(0, pgrp); <=================
if (mode == FORK_FG)
xtcsetpgrp(ttyfd, pgrp) <=============
setsignal(SIGTSTP);
setsignal(SIGTTOU);
} else
#endif
> 2. We have a simple little keyboard handler tied to this app that:
> a. Turns echo off
> b. Turns canonical mode off
> c. Turns extended input processing off
> d. Turns signal chars off
> e. Make I/O non-blocking (G_IO_FLAG_NONBLOCK)
> Essentially - buf.c_lflag &= ~(ECHO|ICANON|IEXTEN);
>
> If the default KB/IO settings are not returned to their original state,
> it seems as though these attributes are passed from the application back
> to the shell (ash), which then messes with the next app that is started
> from the shell. For example, if you start up 'vi' right after the
> previous app terminates, you will see the following msg in 'vi':
>
> last_cmd_overrun
If I run "less <file" and then kill -9 it, ash indeed gets pretty confused,
bash fares a bit better (restores _some_ of tty params) but still
at least loses echo (does not echo typed characters anymore).
(vi is pretty buggy by itself since there seems to be no active users
of it at the moment. sorry)
> I was wondering if there is a setting for ash that prevents applications
> that are fork'ed and exec'ed from ash from messing with the terminal
> settings? It seem as though the shell should be responsible for making
> sure that everything is returned to a known good state after an
> application exits and should not rely on the application for making sure
> everything is returned properly.
This is currently not done, but it can be. Look into ash.c, maybe you can
figure out how. :)
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
