CoSign: Collaborative Single Sign-On  

cosign-discuss at
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:
> pusher.c
> Revision 1.35.  BTW, I don't think this is a bug in libc.  See:
> "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