[Linux-ha-dev] Logging mess
alanr at unix.sh
Tue Mar 16 16:22:11 MST 2004
Lars Marowsky-Bree wrote:
> On 2004-03-16T14:39:04,
> Alan Robertson <alanr at unix.sh> said:
>>>How does it get started/restarted though, and how should absence of the
>>>logging daemon be handled (ie, it died)?
>>Make an init script for it. (?)
> Well, if it's strictly a heartbeat-infrastructure thing, it should
> probably be started in there too.
Of course, heartbeat will restart it if it dies (if it's a client). But,
if it's essential to heartbeat's own well-being, heartbeat probably should
treat the logging daemon as a default client, and spawn it automatically.
Right now heartbeat won't start clients unless it's fully "up" - for good
reason - so starting it beforehand might be a better choice.
I don't mind having several "services" started by different init scripts -
and declaring dependencies between them. I'm not certain enough to say for
sure how this ought to work.
There is a bit of a bootstrap problem - probably you want to start the
logging daemon first, but you want it to register with apphbd, and you want
apphbd to use the logging daemon ;-). Clearly some kind of retry strategy
seems best. I'd suggest starting the logging daemon first - but I can
imagine reasons to do it either way.
>>>cl_log_set_logfile() calls would only be used as fallbacks if the
>>>logging daemon was unavailable, and clients would try to reconnect to it
>>>every so often.
I would suggest that we don't mess with these calls at all - but that we
fall back to some default logging with syslog (probably as daemon). If
those old calls are in a particular piece of code, then they still get
obeyed. Again, this is so things continue to work as they do now without
having to rely on the logging daemon if we don't want to, and allow us to
write test programs that run without the logging daemon running.
It makes it possible for applications that use our libraries to not require
*all* of the infrastructure baggage.
But, I'm not fanatic on the exact details - yet ;-).
>>Or, it could register with the apphbd daemon, whose job it is to do exactly
>>this kind of thing. ;-)
> I know how to register with the apphbd, but how is that recovery process
> etc working? We eventually need to tackle that anyway for heartbeat
> itself should /probably/ run under apphbd, but the recoverymgrd ... I'm
> not sure how to use it.
I've never tried it (recoverymgrd) myself. But, it would be cool if we
actually used the stuff we wrote ;-)
As you point out, heartbeat should run under apphbd too. That's on my todo
list for this year.
Alan Robertson <alanr at unix.sh>
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
More information about the Linux-HA-Dev