Bug: deadlock from msyslog

Gary E. Miller gem at rellim.com
Tue Mar 22 04:07:58 UTC 2016


Yo Hal!

On Mon, 21 Mar 2016 20:23:41 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> esr at thyrsus.com said:
> > I just ported in the Classic fix "[Bug 2814] msyslog deadlock when
> > signaled." I think that'll do it for this one.   
> 
> Is there any software that will check signal handlers to see if they
> call (or call anything that calls) any non-signal-safe routines?

# man signal

	"The behavior of signal() varies across UNIX versions, and has also var‐
	ied historically across different versions of Linux.   Avoid  its  use:
	use sigaction(2) instead."

That bears repeating:

	"Avoid  its  use: use sigaction(2) instead."

You may 'fix' msyslog, but signal() is inherently not thread safe.  From
the man page:

	"The effects of signal() in a multithreaded process are unspecified."


> The case I'm thinking of is a trap handler that catches a
> fatal error and wants to print out a useful message and then exit
> somewhat cleanly.

Check out "man 7 signal", almost nothing is legal to call from within
a signal.  You can't even open() of fopen() anything.  About the best you
can do is write(STDERR,) and exit().

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160321/a52005ba/attachment.bin>


More information about the devel mailing list