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
[EMAIL PROTECTED]
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
> [EMAIL PROTECTED]
>
> 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
> > [EMAIL PROTECTED]
> >
> > 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
