Topics: AIX, System Admin

The default log file has been changed

You may encounter the following entry now and then in your errpt:

IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
573790AA 0528212209 I O RMCdaemon The default log file has been changed.
An example of such an entry is:
-----------------------------------------------------------------
LABEL: RMCD_INFO_2_ST
IDENTIFIER: 573790AA

Date/Time: Sun May 17 22:11:46 PDT 2009
Sequence Number: 8539
Machine Id: 00GB214D4C00
Node Id: blahblah
Class: O
Type: INFO
Resource Name: RMCdaemon

Description
The default log file has been changed.

Probable Causes
The current default log file has been renamed and a new log file created.

Failure Causes
The current log file has become too large.

Recommended Actions
No action is required.

Detail Data
DETECTING MODULE
RSCT,rmcd_err.c,1.17,512
ERROR ID
6e0tBL/GsC28/gQH/ne1K//...................
REFERENCE CODE

File name
/var/ct/IW/log/mc/default
This error report entry refers to a file that was created, called /var/ct/IW/log/mc/default. Actually, when the file reaches 256 Kb, a new one is created, and the old one is renamed to default.last.

The following messages can be found in this file:
2610-217 Received 193 unrecognized messages in the last 10.183333 minutes. Service is rmc.
This message more or less means:

"2610-217 Received count of unrecognized messages unrecognized messages in the last time minutes. Service is service_name.
Explanation:
The RMC daemon has received the specified number of unrecognized messages within the specified time interval. These messages were received on the UDP port, indicated by the specified service name, used for communication among RMC daemons. The most likely cause of this error is that this port number is being used by another application.

User Response:
Validate that the port number configured for use by the Resource Monitoring and Control daemon is only being used by the RMC daemon."

Check if something else is using the port of the RMC daemon:
# grep RMC /etc/services
rmc                      657/tcp                # RMC
rmc                      657/udp                # RMC
# lsof -i :657
COMMAND     PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
rmcd    1384574 root    3u  IPv6 0xf35f20      0t0  UDP *:rmc
rmcd    1384574 root   14u  IPv6 0xf2fd39      0t0  TCP *:rmc (LISTEN)
# netstat -Aan | grep 657
f1000600022fd398 tcp     0   0  *.657    *.*   LISTEN
f10006000635f200 udp     0   0  *.657    *.*
The socket 0x22fd008 is being held by proccess 1384574 (rmcd).
No, it is actually the RMC daemon that is using this port, so this is fine.

Start an IP trace to find out who's transmitting to this port:
# iptrace -a -d host1 -p 657 /tmp/trace.out
# ps -ef | grep iptrace
root 2040018 iptrace -a -d lawtest2 -p 657 /tmp/trace.out
# kill 2040018
iptrace: unload success!
# ipreport -n /tmp/trace.out > /tmp/trace.fmt
The IP trace reports only shows messages from RMC daemon of the HMC:
Packet Number 3
====( 458 bytes received on interface en4 )==== 12:12:34.927422418
ETHERNET packet : [14:5e:81:60:9d -> 14:5e:db:29:9a] type 800 (IP)
IP header breakdown:
        < SRC =    10.231.21.55 >  (hmc)
        < DST =    10.231.21.54 >  (host1)
        ip_v=4, ip_hl=20, ip_tos=0, ip_len=444, ip_id=0, ip_off=0 DF
        ip_ttl=64, ip_sum=f8ce, ip_p = 17 (UDP)
UDP header breakdown:
        
        [ udp length = 424 | udp checksum = 6420 ]
00000000     0b005001 f0fff0ff e81fd7bf 01000100   |..P.............|
00000010     ec9f95eb 85807522 02010000 05001100   |......u"........|
00000020     2f001543 a88ba597 4a03134a 50a00200   |/..C....J..JP...|
00000030     00000000 00000000 4ca00200 00000000   |........L.......|
00000040     85000010 00000000 01000000 45a34f3f   |............E.O?|
00000050     fe5dd3e7 3901eb8d 169826cb cc22d391   |.]..9.....&.."..|
00000060     e6045340 e2d4b997 1efc9b78 f0bfce77   |..S@.......x...w|
00000070     487cbbd9 21fda20c f5cf8920 53d2f55a   |H|..!...... S..Z|
00000080     2de3eb9d 62ba1eef 10b80598 e90f1918   |-...b...........|
00000090     9cd9c654 8fb26c66 2ba6f7f0 7d885d34   |...T..lf+...}.]4|
000000a0     aa8d9f39 d2cd7277 7a87b6aa 494bb728   |...9..rwz...IK.(|
000000b0     53dea666 65d92428 e2ad90ed 73869b8d   |S..fe.$(....s...|
000000c0     d1deb7b2 719c27c5 e643dfdf 50000000   |....q.'..C..P...|
000000d0     00000000 00000000 00000000 00000000   |................|
********
00000150     02007108 00000000 4a03134a 40000000   |..q.....J..J@...|
00000160     9c4670e2 7ec24946 de09ff13 f31c3647   |.Fp.~.IF......6G|
00000170     f2a41648 3ae78b97 cd4f0177 d4f83407   |...H:....O.w..4.|
00000180     37c6cdb0 4f089868 24b217b1 d37e9544   |7...O..h$....~.D|
00000190     371bd914 eb79725b ef68a79f d50b4dd5   |7....yr[.h....M.|
To start iptrace on LPAR, do:
# startsrc -s iptrace -a "-b -p 657 /tmp/iptrace.bin"
To turn on PRM trace, on LPAR do:
# /usr/sbin/rsct/bin/rmctrace -s ctrmc -a PRM=100
Monitor /var/ct/3410054220/log/mc/default file on LPAR make sure you see NEW errors for 2610-217 log after starting trace, may need to wait for 10min (since every 10 minutes it logs one 2610-217 error entry). To monitor default file, do:
# tail -f /var/ct/3410054220/log/mc/default
To stop iptrace, on LPAR do:
# stopsrc -s iptrace
To stop PRM trace, on LPAR do:
# /usr/sbin/rsct/bin/rmctrace -s ctrmc -a PRM=0
To format the iptraces, do:
# ipreport -rns /tmp/ipt > /tmp/ipreport.out
Collect ctsnap data, on LPAR do:
# ctsnap -x runrpttr
When analyzing the data you may find several nodeid's in the packets.

On HMC side, you can run: /usr/sbin/rsct/bin/rmcdomainstatus -s ctrmc to find out if 22758085eb959fec was managed by HMC. You will need to have root access on the HMC to run this command. And you can get a temporary password from IBM to run with the pesh command as the hscpe user to get this root access. This command will list the known managed systems to the HMC and their nodeid's.

Then, on the actual LPARs run /usr/sbin/rsct/bin/lsnodeid to determine the nodeid of that LPAR. If you find any discrepancies between the HMC listing of nodeid's and the nodeid's found on the LPAR's, then that is causing the errpt message to appear about the change of the log file.

To solve this, you have to recreate the RMC deamon databases on both the HMC and on the LPARs that have this issue: On HMC side run:
# /usr/sbin/rsct/bin/rmcctrl -z
# /usr/sbin/rsct/bin/rmcctrl -A
# /usr/sbin/rsct/bin/rmcctrl -p
Then run /usr/sbin/rsct/install/bin/recfgct on the LPARs:
# /usr/sbin/rsct/install/bin/recfgct
0513-071 The ctcas Subsystem has been added.
0513-071 The ctrmc Subsystem has been added.
0513-059 The ctrmc Subsystem has been started.
Subsystem PID is 194568.
# /usr/sbin/rsct/bin/lsnodeid
6bcaadbe9dc8904f
Repeat this for every LPAR connected to the HMC. After that, you can run on the HMC again:
# /usr/sbin/rsct/bin/rmcdomainstatus -s ctrmc
# /usr/sbin/rsct/bin/lsrsrc IBM.ManagedNode Hostname UniversalId
After that, all you have to do is check on the LPARs if any messages are logged in 10 minute intervals:
# ls -als /var/ct/IW/log/mc/default




If you found this useful, here's more on the same topic(s) in our blog:


UNIX Health Check delivers software to scan Linux and AIX systems for potential issues. Run our software on your system, and receive a report in just a few minutes. UNIX Health Check is an automated check list. It will report on perfomance, capacity, stability and security issues. It will alert on configurations that can be improved per best practices, or items that should be improved per audit guidelines. A report will be generated in the format you wish, and the report includes the issues discovered and information on how to solve the issues as well.

Interested in learning more?