Date: Sun, 30 Jul 2000 23:51:36 -0400 From: Jim Bloom <bloom@acm.org> To: Jonathan Lemon <jlemon@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_event.c Message-ID: <3984F7C8.AE445EC2@acm.org> References: <200007272306.QAA41002@freefall.freebsd.org> <3983A329.B37CE8BA@acm.org> <3984F010.1A208994@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I did a little more testing of this problem just now. A SIGKILL does not kill the process but will lock up the machine. Truss reports the SIGKILL being continuously sent to the process. If I break into DDB, and then panic, I get a panic "lockmgr: pid XXX, not exclusive lock holder 0 unlocking". The pid is for the tail command. Jim Bloom bloom@acm.org Jim Bloom wrote: > > I didn't have much time for testing, but backing out this change fixes the > problem tail. For some reason, the signal never gets delivered to the process. > The manual page states that the kevent processing is lower priority than signal > handling and that the signal will get processed as normal before the event will > will be logged. > > In fact, I witnessed a case where a SIGKILL would not kill the process after a > SIGINT. > > Jim Bloom > bloom@acm.org > > Jim Bloom wrote: > > > > I am having problems with "tail -f" hanging the machine. I don't know if this > > change is related, but I suspect that it might be. > > > > I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I > > interrupted the tail, the machine hung. I then tried to figure out what was > > causing the problem. Eventually, I tracked the problem down to tail. The > > machine would respond to pings, but the keyboard was useless. It would not > > shutdown as well. One test I tried was to run tail -f under truss. This > > actually kept the machine somewhat usable. Top showed truss using 75% of the > > CPU and tail using the other 25%. System time was running over 80%. Truss > > reported that tail kept receiving the signal (indefinitely as far as I could > > tell) at a high rate of speed. > > > > I tried to get a kernel core dump several times by breaking into ddb, but I > > never had any luck. Here is the backtrace copied by hand: > > > > vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 > > kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 > > syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 > > Xinit0x80_syscall() at Xint0x80_syscall+0x25 > > > > My kernel and source tree both date from 20:00-22:00 EDT on July 28. > > > > I found the problem to be quite repeatable by simply going "tail -f file" (the > > file does not need to change) and then hitting an interrupt on the keyboard. > > > > Let me know if I can be of any assistance in tracking this problem down. I > > might try to spend some time tomorrow figuring out what is happening. > > > > Jim Bloom > > bloom@acm.org > > > > Jonathan Lemon wrote: > > > > > > jlemon 2000/07/27 16:06:15 PDT > > > > > > Modified files: > > > sys/kern kern_event.c > > > Log: > > > Have kevent() automatically restart if interrupted by a signal. If this > > > is not desired, then the user can register an EV_SIGNAL filter to > > > explicitly catch a signal event. > > > > > > Change requested by: jayanth, ps, peter > > > "Why is kevent non-restartable after a signal?" > > > > > > Revision Changes Path > > > 1.12 +3 -6 src/sys/kern/kern_event.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3984F7C8.AE445EC2>