[OpenAFS-devel] Why do afsd daemons loop tightly after receiving a SIGHUP?

[Derrick J Brashear]

On Thu, Aug 02, 2001 at 10:50:15PM -0400, Derek Atkins wrote:
> Well, yea.  It looks like we should be able to flush_signals() on the
> current thread context.  I _thought_ that's what we were doing
> already.  Looking at src/afs/LINUX/osi_sleep.c, in afs_osi_Wait() we
> do actually call flush_signals() if osi_TimedSleep() returns non-zero
> and aintok (the third argument to afs_osi_Wait()) is zero.
> 
> So, this _should_ be doing the right thing, provided aintok is zero.
> And indeed, it definitely looks like all the calls to afs_osi_Wait
> indeed pass zero as the third argument.  So, we should be flushing
> the signals.

Except in HandleFlock (afs/VNOPS/afs_vnop_flock.c)

> AHH, the flush_signals() code is only activated if AFS_GLOBAL_SUNLOCK
> is defined.  And that is only defined if AFS_SMP is defined.  This
> means that signals are only flushed properly on SMP machines!  I bet
> that's the problem.  :)

Making the flush_signals() path be active in all cases makes the problem
less prevalent but some thread(s) don't follow that code path, so more
work is needed.

-D