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

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