[Linux-ha-dev] Logging mess

[Alan Robertson]

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