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

[Derek Atkins]

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

-derek

Daniel Jacobowitz <dmj+afs@andrew.cmu.edu> writes:

> Well, except for those we can't ignore, of course.  Except that if we
> ignore the signals inside of the syscall, when we're already in kernel
> mode, we can probably get it to ignore them anyway.  It'd be worth it
> to clear the pending signal anyway; it's not very complicated.
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available