On 2008-06-24T04:12:48, Joe Bill <[EMAIL PROTECTED]> wrote:
> ha_logger -t "${HA_LOGTAG}" "$@"
> if [ "$?" -eq "0" ] ; then
> return 0 !!! if successful
> fi
>
> where, if ha_logger fails then ha_log() attempts to write directly to a
> logfile and to a debugfile. If ha_logger succeeds, ha_log() completes without
> writing to the log files.
>
> If there are intermittent network problems, assembling the patches of log
> written in the syslog managed files, and those patches written in the local
> logfiles should guarantee maximum fun on a slow day.
Ah, yeah, that is weird.
But I've never actually seen ha_logger fail, in particular not with ha_logd.
However, you must realize that this is safe-guard in case something
/does/ go wrong, for example with writing to the logd (just that I've
never seen that happen, ever). In that case, if it didn't fall back to
recording the logs /somewhere/, they'd be lost.
> After massaging the priority code a bit, this is what ocf_log() does:
>
> (/usr/lib/ocf/resource.d/heartbeat/.ocf-shellfuncs)
>
> if [ "${__OCF_PRIO}" = "DEBUG" ]; then
> ha_debug "${__OCF_PRIO}: $__OCF_MSG"
> else
> ha_log "${__OCF_PRIO}: $__OCF_MSG"
> fi
>
> Which doesn't make such a difference IMHO.
The difference is that ocf_log is portable to RHT, ha_log is not. The
name of the function call is important. ha_log might go away when we
clean up the shell libraries - no OCF script should call that.
> > The daemon can write to disk too,
> I apologize for having not looked in the source. Just in one line,
> how, what for, and when does the HA logging relay "write to disk" ?
It writes to disk if you specify that you don't want it to relay to
syslog, but to logfiles.
It never directly sends messages on the network, though this would
probably be a neat trick to avoid needing to modify syslog on the
clients.
> I'm afraid I don't see the benefit of "buffering" a message that is
> intended to be written to disk.
The point is to decouple the cluster stack from the possibly blocking
write() call, either to the syslog socket or the disk. That's the main
reason for its existence.
> Yes, but then ha_log() really needs to be fixed because some folks
> like me really like seeing that all log messages be written to local
> disk first, ***before*** being sent out on that "lossy" network, not
> only when the network is down or flakey as handled by ha_log() today.
Your analysis is not correct. ha_logger will not write directly to disk
if there's a network problem, but if the local logging system (syslog
or logd) have failed for whatever reason.
> Would you agree that ha_log() should write the local log file and/or
> debug file first, before calling ha_logger ? This would fulfill the
> condition that the message be saved once before being sent out on the
> network.
No. I do not agree.
> > Sure. The date should be calculated just once.
> > Keep in mind that this is legacy though.
> If writing log messages to local log and debug files is to be considered as
> "legacy", should we understand that for a RA to effectively and correctly
> write to local files, the RA should handle it by itself and not rely on
> ha_log() to do it, or even expect doing it in the future ?
I don't know where you got this idea. RAs should call ocf_log().
I meant that ha_log is a legacy call, and that the code path you outline
- with the date being calculated in the shell library is legacy -
ha_logger will handle this.
> Do we keep specifying to ha_log():
>
> - the log facility through HA_LOGFACILITY
You should not set this manually. This is set in the configuration and
the RA should not mess with it.
> - the log priority as the uppercase prefix in the message itself,
> extending the available prefixes to *all* those support be 'logger' ?
ha_logger could be extended to support the additional prefixes, sure. We
accept patches.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
