[Linux-ha-dev] cl_log questions
Andrew Beekhof
beekhof at gmail.com
Wed Dec 22 04:07:14 MST 2004
On Wed, 22 Dec 2004 11:27:07 +0100, Roberto Nibali <ratz at tac.ch> wrote:
> Dear Guochun,
>
> Thanks for you help. I realized that I should have posted this to the linux-ha
> list instead of the linux-ha-dev list. Apologies.
>
> > Normally you should see no messages in console.
>
> This is exactly why I'm confused.
>
> > Only when some error happens in logging a message that the message will be sent to console.
>
> What kind of error could that be? syslog-ng is started at this point. The
> remaining cluster messages do get written the their appropriate files.
>
> >>Does the cl in cl_log() refer to cluster log or command line log?
> > What is the reason to not send those messages to syslog? Am I forgetting something?
> >
> > I think cluster log makes more sense :).
>
> I was half kidding, yes :).
>
> > There are other files like cl_msg.c cl_signal.c....
> > I believe it is cluster <something> shorten to cl :)
>
> I believe you without doubts.
>
> > By sending a message to syslog, that message will be in /var/log/messages, have you checked that?
>
> I have following syslog-ng.conf (extremely simplified for posting) which is
> active long before heartbeat gets forked off in the bootscripts:
>
> options {
> sync (0);
> time_reopen (10);
> log_fifo_size (1000);
> long_hostnames (on);
> use_dns (no);
> use_fqdn (no);
> create_dirs (yes);
> keep_hostname (yes);
> };
>
> source s_int {
> internal();
> unix-stream("/dev/log" max-connections(256));
> udp(ip(172.23.23.23) port(514));
> file("/proc/kmsg");
> };
>
> filter f_auth {
> facility(auth,authpriv);
> };
>
> filter f_cis {
> facility(local1);
> };
>
> filter f_cmd {
> facility(local0);
> };
>
> filter f_cron {
> facility(cron);
> };
>
> filter f_eventlog {
> facility(local6);
> };
>
> filter f_fw {
> facility(local2);
> };
>
> filter f_ids {
> facility(local7);
> };
>
> filter f_kern {
> facility(kern);
> };
>
> filter f_mail {
> facility(mail);
> };
>
> filter f_msgs {
> facility(daemon, lpr, news, user, uucp,
> local3, local4, local5);
> };
>
> filter f_prm {
> facility( local5 );
> };
>
> filter f_syslog {
> facility( syslog );
> };
>
> filter f_syslogsurfer {
> not facility( local6 );
> };
>
> filter f_ras {
> filter( f_auth ) and (
> (
> program("sshd") and not match(": debug:")
> ) or (
> program("login")
> )
> );
> };
>
> filter f_tfx {
> facility(kern) and
> match(" DENY ");
> };
>
> filter f_tfx3 {
> facility(kern) and
> match(" DROP:");
> };
>
> filter f_remote {
> filter(f_err) or
> filter(f_ras) or
> filter(f_tfx3) or
> filter(f_tfx);
> };
>
> destination d_auth {
> file("/var/log/authlog");
> };
>
> destination d_cis {
> file("/var/log/ciscolog");
> };
>
> destination d_cmd {
> file("/var/log/cmdlog");
> };
>
> destination d_cron {
> file("/var/log/cronlog");
> };
>
> destination d_eventlog {
> file("/var/log/eventlog");
> };
>
> destination d_fw {
> file("/var/log/fwlog");
> };
>
> destination d_ids {
> file("/var/log/idslog");
> };
>
> destination d_kern {
> file("/var/log/kernlog");
> };
>
> destination d_mail {
> file("/var/log/maillog");
> };
>
> destination d_msgs {
> file("/var/log/messages");
> };
>
> destination d_prm {
> file("/var/log/prmlog");
> };
>
> destination d_syslog {
> file("/var/log/syslog");
> };
>
> log {
> source(s_int);
> filter(f_kern);
> destination(d_kern);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_ids);
> destination(d_ids);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_fw);
> destination(d_fw);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_auth);
> destination(d_auth);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_cmd);
> destination(d_cmd);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_cron);
> destination(d_cron);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_eventlog);
> destination(d_eventlog);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_mail);
> destination(d_mail);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_msgs);
> destination(d_msgs);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_syslog);
> destination(d_syslog);
> flags(final);
> };
>
> log {
> source(s_int);
> filter(f_prm);
> destination(d_prm);
> flags(final);
> };
>
> So the following log messages all go to /var/log/messages. Excerpt:
>
> Dec 22 04:25:51 s_int at hot heartbeat[2742]: info: ping heartbeat started.
> Dec 22 04:25:51 s_int at hot heartbeat[2754]: info: pid 2754 locked in memory.
> Dec 22 04:25:51 s_int at hot heartbeat[2742]: info: pid 2742 locked in memory.
> Dec 22 04:25:51 s_int at hot heartbeat[2742]: info: Local status now set to: 'up'
> Dec 22 04:25:51 s_int at hot heartbeat[2756]: info: pid 2756 locked in memory.
> Dec 22 04:25:52 s_int at hot heartbeat[2755]: info: pid 2755 locked in memory.
> Dec 22 04:25:52 s_int at hot heartbeat[2742]: info: Link 172.23.2.30:172.23.2.30 up.
> Dec 22 04:25:52 s_int at hot heartbeat[2742]: info: Status update for node
> 172.23.2.30: status ping
> Dec 22 04:25:57 s_int at hot cl_status[2804]: info: start:optind: 1
> argv[optind+1]: hot.terreActive.CH
> Dec 22 04:25:57 s_int at hot cl_status[2804]: info: optind: 1 argv[optindex+1]:
> hot.terreActive.CH
> Dec 22 04:25:57 s_int at hot cl_status[2804]: info: End: optind: 1 argv[optind+1]:
> hot.terreActive.CH
> Dec 22 04:25:57 s_int at hot cl_status[2804]: ERROR: return value:0
> Dec 22 04:25:57 s_int at hot cl_status[2806]: info: start:optind: 1
> argv[optind+1]: (null)
I believe that the cl_status messages have been cleaned up since. The
ERROR log in particular I know has been removed.
>
> It's those for message upon boot I don't understand. And they drive me nuts,
> every time I see them ;). Unfortunately I do not have enough time to investigate
> this issue but I will sometime ... Besides that, heartbeat has the weirdest
> logging "concept" of all open source software we've ever deployed.
Can you be a little more specific about what is weird about it? You
think there is too much being logged as INFO or is there something
else? I dont really have an opinion yet one way or the other, I'm
just interested.
> We have to
> heavily tune our data regression software to extract meaningful classes of events.
>
> Thanks + best regards,
> Roberto Nibali, ratz
> --
> -------------------------------------------------------------
> addr://Rathausgasse 31, CH-5001 Aarau tel://++41 62 823 9355
> http://www.terreactive.com fax://++41 62 823 9356
> -------------------------------------------------------------
> terreActive AG Wir sichern Ihren Erfolg
> -------------------------------------------------------------
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
More information about the Linux-HA-Dev
mailing list