Bug 27242
| Summary: | SIGHUP propagation failure to processes of switched user and the command may run infinitely | ||
|---|---|---|---|
| Product: | Base System | Reporter: | jhkang <jhkang> |
| Component: | kern | Assignee: | Ceri Davies <ceri> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.3-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Follwing patch for kernel may help to solve the problem. I could not guess side effect (e.g. security hole) of this patch. vm-freebsd# pwd /usr/src/sys/kern vm-freebsd# diff kern_sig.c.orig kern_sig.c 97a98 > * 20010509 - jhkang - add SIGHUP propagation via session (terminal?) 101c102 < ((sig) == SIGCONT && (q)->p_session == (p)->p_session)) --- > (((sig) == SIGCONT) || ((sig) == SIGHUP) && (q)->p_session == (p)->p_session)) the patch is avaliable at http://ai.ce.pusan.ac.kr/~jhkang/files/patch.kern.infinite-loop.20010509.jhkang --- Jaeho Kang jhkang@isofree.net On Thu, 10 May 2001 jhkang@isofree.net wrote: > >Description: > Top utilitiy and may other utiltities that control terminal directly > and does not have explicit checking eof condition may not > die and captures cpu resource continuely > if an user switched another user, run the command and the controlling terminal > disconnected unexpectedly. > ... > >Fix: > APPLICATION LEVEL SOLUTION > check EOF condition in command reading loop. > patch top.c (/usr/src/usr.bin/top/top.c in FreeBSD 4.3) as following > ... > KERNEL(?) LEVEL? > I suspect something is blocking propating of SIGHUP signal to the processes. > The charge may be *kernel*, su or termcap lib. I believe SIGHUP propagation works as intended (if not correctly). There are cases where POSIX requires SIGHUP to _not_ be delivered to all the children. Applications that don't check for read() failing are just broken. Bruce State Changed From-To: open->feedback This looks like a bug in `top' that was fixed quite a while ago. Can you confirm that the problem is fixed in more recent releases? State Changed From-To: feedback->closed Feedback timeout (6 months or more). I will handle any feedback that this closure generates. Responsible Changed From-To: freebsd-bugs->ceri Feedback timeout (6 months or more). I will handle any feedback that this closure generates. |
Top utilitiy and may other utiltities that control terminal directly and does not have explicit checking eof condition may not die and captures cpu resource continuely if an user switched another user, run the command and the controlling terminal disconnected unexpectedly. Fix: APPLICATION LEVEL SOLUTION check EOF condition in command reading loop. patch top.c (/usr/src/usr.bin/top/top.c in FreeBSD 4.3) as following bash2.05# diff top.c.orig top.c 671a672 > int retval; 679c680,688 < (void) read(0, &ch, 1); --- > /* 2001/05/09 - jhkang */ > /* SUMMARY: patch for an abnormal behavior (infinite loop) */ > /* SITUATION: unexpected disconnection running on root account */ > /* SOLUTION: add eof condition test */ > /* (void) read(0, &ch, 1); */ > retval = read(0, &ch, 1); > if (retval == 0) { > quit(0); > } the patch file is available at http://ai.ce.pusan.ac.kr/~jhkang/files/patch.top.infinite-loop.20010509.jhkang.patch KERNEL(?) LEVEL? I suspect something is blocking propating of SIGHUP signal to the processes. The charge may be *kernel*, su or termcap lib. This problem also occure FreeBSD 3.5-STABLE/i386, NetBSD 1.4.1/macppc. How-To-Repeat: login in a system. switch to another user with su command. run a command (top, lynx or w3m, ...) that control terminal directly and does not have explicit checking eof (or error?) of input stream. disconnect the terminal by force. (may be telnet client) monitor cpu time usage (e.g. with another top utility)