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

[Daniel Jacobowitz]

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.
> 
> 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.  :)

That might do it, yeah :)  I thought I'd never seen this problem, and I
know I've sent signals to afsd on my SMP Linux machines.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer