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

Jim Bloom

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
> 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to