Checker directive - debug info

Dick Middleton dick at fouter.net
Sun Jun 24 21:16:19 CEST 2012


On 06/24/12 03:01, Teddy Hogeborn wrote:
> Dick Middleton <dick at fouter.net> writes:
> 
>>>>         3. puts funny characters in logger

> So, your syslog daemon doesn't seem to understand the RFC 5424 format.
> Also, neither does ours (rsyslog) - we can see the same characters in
> the log here.  So I think we can chalk this one up to rsyslog not
> following RFC 5424 and move on.

Googling around doesn't turn up much although it seems that the syslog
protocol doesn't, or didn't until recently, support unicode.  So no logger
daemon would handle this correctly. Rsyslog seems to have some non-unicode
character interpretation available as a stop-gap.  I think my choice would be
to not send unicode to the logger until it is supported.  But then I speak
English so it doesn't make any difference to me :-)

> Yeah, but the thing is, the code doing the waitpid is there to cover for
> this exact race condition - in case the process completed before we
> could add the subprocess to the gobject event loop.  When a process
> exits, a zombie should remain until waitpid() is called to get the exit
> status - that's what zombies are for.  For waitpid to give ECHILD, this
> means there is no zombie - either no subprocess was started, or
> something else did waitpid() already; neither seems very likely.

That should probably be investigated.

> Now, if there is no subprocess at all after we just started a checker,
> what should we consider the checker result to be?

There's a thing!  I suppose if there is no explanation forthcoming then one
should use a retry mechanism.  That seems a lot of work when the 'sleep 1'
workaround is available.  I think by preference I would introduce a check
disable option somehow; the ':'/'true' solution spawns processes unnecessarily
and so is not ideal.

Anyway, we're a long way from "Something wicked is going on with that
system,.." so that's good.  I've got a workaround and you've got something to
ponder.

Thanks again for your support.  It's been quite interesting, if a bit
frustrating at times.

Cheers

Dick



More information about the Mandos-Dev mailing list