Date: Sat, 23 Sep 2000 01:44:51 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: groggy@iname.com Cc: questions@freebsd.org Subject: Re: losing controlling terminal Message-ID: <14796.20835.127779.329418@guru.mired.org> In-Reply-To: <132765059@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
groggy@iname.com writes: > > > > FBSD 3.51 > > > > why is it that when you lose the controlling > > > > terminal (such as an MS client killing a TELNET window) > > > > the processes activated by that window on the FBSD server > > > > keep running - i sometimes see my HD LED light on cuz > > > > 2 process of "lynx" or somehting are eating up 50% each > > > > of my CPU time - cuz a user killed their telnet client. > > > > > > I suspect it's a bug in lynx (or something). It's ignoring HUP signals > > > and EOFs while doing raw I/O from the terminal, so it sits there > > > getting an EOF and not being happy about it. Use gcore to get a core > > > image or use gdb on the process to figure out where it is and what > > > it's doing. Then fix it :->. > well - no - it's not lynx, cuz it happens with BSD ftp, telnet, talk, > etc, etc, with everythign as far as i can tell. > FBSD doesn't seem to understand: > > no user/tty = kill user processes. Well, I don't see that behavior. Then again, I don't run things from Windows. > i don't know if it's related, but i can > also kill Xwindow quite often, and yet - BSDI > Netscape 4.73 is still running - doing the same > kind thing in terms of gobbling up all available > CPU time in the background after the controlling > terminal is gone. That doesn't sound like a Windows problem :-). Possibly you're enabling nohup somewhere along the way? I do remember going to strange contortions on BSD 4.x (adding /dev/cia, which killed you if you persisted from reading from it, and code to point file descripters aimed at closed ttys at /dev/cia) to deal with this, but that was easier than fixing all the things with bugs like I described. One of the symptoms is that the context switches go ballistic when this happens, because each syscall to read does nothing but two context switches. It would still help to do the debugging bit (not on Netscape, though) to see what the process is doing. <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14796.20835.127779.329418>