Repeating messages in SYSLOG after starting cluster

[TheJuiceman]

Hi everyone,

I am getting the following messages in my syslog when forming the cluster:

Apr 15 23:54:55 node cmcld: Turning on safety time protection
Apr 15 23:54:55 node cmcld: 2 nodes have formed a new cluster, sequence #43
Apr 15 23:54:55 node cmcld: The new active cluster membership is: node2(id=1
), node(id=2)
Apr 15 23:54:55 node cmlvmd: Clvmd initialized successfully.
Apr 15 23:54:55 node inetd[4434]: hacl-cfg/tcp: Connection from 127.0.0.1 at
Sat Apr 15 23:54:55 2006
Apr 15 23:54:55 node inetd[4435]: ident/tcp: Connection from 127.0.0.1 at Sa
t Apr 15 23:54:55 2006

After that I continue to get the last two inetd messages (the hacl-cfg/tcp and ident/tcp messages) repeatedly. The cluster is working, but I would like to resolve this problem that is writing to the syslog.

Thanks for your help.

[Senthil Kumar .A_1 · Accepted solution]

Hi Juiceman,

All these messages that you see is just a informational messages. Just because you see a line in syslog.log file it does not mean , it is a error message. There are different level of info that gets logged to syslog.log file,

e.g. emerg, alert, crit, err, warning, notice, info and debug.

The above messages by cm* daemons belongs to the category of "info" by the facility named "daemon". You will have to trade of for this implementation. The issue is I can't differentiate among the facility. For example cm* log's is a subset of "daemon" facility. If I redirect the logs of the facility of "daemon" to some other log file, I would then be directing even the logs of other network related daemon logs also. If you are ready for this you can do the following....

edit the file "/etc/syslog.conf"

1) add the following line, so that all the "info and above" logs are directed to "/var/adm/syslog/daemon.log"

daemon.info /var/adm/syslog/daemon.log

2)modify the line containing "/var/adm/syslog/syslog.log" to contain "daemon.none" as shown below...

*.info;mail.none;daemon.none /var/adm/syslog/syslog.log

save the file after modifying as stated above and then recycle the the syslogd daemon,...

kill -HUP $(cat /var/run/syslog.pid)

now you can verify your action by checking the log files in /var/adm/syslog directory.

By now any cm* related logs will be directed to /var/adm/syslog/daemon.log. But caution, now all your system admins need to be aware of such a change aswell.

Regards,
Senthil Kumar .A

[melvyn burnard]

The last two messages are nothing to do with Serviceguard per se, they are being logged by inetd daemon.
You need to look at what logging you are doing for inetd.

[John Bigg]

As previously stated, these messages are logged by inetd and indicate a connection being made over the loopback address to the SG configuration port and the ident port. This is probably caused by someone or something regularly running a Serviceguard command. You would see similar messages if you ran a cmviewcl.

If you want to stop these messages you can turn off inetd connection logging using inetd -l. Or if you want to determine the source of the connection you need to track down the real command being run and find out what is doing this, cron maybe? You may be able to determine the real command by running repeated ps -ef commands at the times you see the messages in syslog.

[John Bigg]

I just realised you stated that these messages occur after starting the cluster. Therefore they are probably caused by commands from one of the packages started by the cluster. I'd check the package script files to see if any of these do any sort of monitoring by running cmviewcl or similar at regular intervals. This might be configured as a service for example.

[Stephen Doud]

/etc/rc.config.d/netdaemons gives the admin the opportunity to specify additional options to the 'inetd' daemon. The additional hacl-cfg/tcp and ident/tcp messages are a result of setting the "-l" option in the above file.
I believe John is onto something. Serviceguard commands invoke an exercise of the cmclconfd daemon, awakened by inetd (see /etc/inetd.conf). cmclconfd must deal with ident to validate the host requesting the performance of the Serviceguard command. Unless you have a script or cron batch job that executes a Serviceguard command after cluster and package startup, you should not be seeing the messages.

Along that line, we occasionally deal with customers that see abnormally frequent cmviewcl or cmgetconf commands in the process list.
cmgetconf is executed by several non-Serviceguard applications. You may want to monitor the servers' process list to see which Serviceguard command is being exercised.

Unfortunately, not all SG commands are logged in syslog.log, so that file may not help.

You may have to implement a wrapper script on SG commands, in order to locate the source of the messages that you are seeing in syslog.log

See UMCSGKBRC00014697
TITLE: Tracing the source of cmgetconf commands