CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

cosign-discuss at umich.edu
general discussion of cosign development and deployment
 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: [Bug libc/671] New: It appears syslog can go into deadlock when it receives a signal where the signal handler also syslogs]



On Sun, 2005-01-16 at 15:52, Wesley D Craig wrote:
> On 15 Jan 2005, at 21:32, Brett Lomas wrote:
> > FYI, I just reported this bug, because I was seeing it in the cosign
> > daemon when using the replication and stressing it.
> >
> > I have removed all of the sysloging in pusherchld to stop pusherparent
> > from going into deadlock, at least until i hear back on this.
> 
> We noticed this problem some time ago in another project (radmind) and  
> have been fixing all of our projects since.  The CVS HEAD version of  
> cosign has fixed the problem by removing all "interesting" code from  
> all signal handlers.  See:
> 
> 	http://cvs.web.itd.umich.edu/horde/chora/cvs.php?f=cosign/daemon/
> pusher.c
> 
> Revision 1.35.  BTW, I don't think this is a bug in libc.  See:
> 
> 	http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
> 
> "Application Usage."  There is a specific prohibition against calling  
> non-reentrant functions from a signal handler.  Examples of  
> non-reentrant functions include malloc/free and stdio.  While syslog is  
> not specifically mentioned, syslod is not required to be reentrant, and  
> it works an awful lot like printf.
> 

Yeah, but the syslog function is reentrant I am pretty sure. I got the
source and looked the vsyslog function and it does lock etc before
attempting to write to the syslogd socket.

Hmm... we'll see where it goes :)

> :wes
> 



 
Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010