api.log - defunct process - / directory

[John Jimenez]

1) In Feb. We upgraded from an RP7410 to a RP7420, still using HP-UX 11.11. Since day one we have had a defunct process that is always respawns. It always shows the current time.

# ps -ef | grep defunct
root 4026 26563 1 09:33:25 pts/tKb 0:00 grep defunct
root 3855 2945 0 09:32:32 ? 0:00

2) / has been creeping up bit by bit not a lot, but 1% every couple of months. It is not an major issue yet, but I was more comfortable having it between 30%-50%.

/dev/vg00/lvol3 270336 195128 74656 72% /

3) I have been looking to clean up / but have found no cores or any large files to free up space. Yesterday I did a "du -x /" and began to browse the directories that have large amounts of data. I found two files that api.log, and api.log.old. both of these files had yesterdays day. Today both have yesterdays date. According to what's in this file something is running on my RP7420 that is only supposed to run on superdomes and on S-Class. What computers ore S-Class? I thought RP7420 was an evolution of the N-Class? Does it look like something wrong is installed and running on this server, which is why I always have a defunct process respawning?

-------------------Start Event--------------------
User event occurred at Fri Nov 2 00:09:59.055883 2007
Process ID: 3659 (/usr/sbin/stm/uut/bin/.../dm_chassis) Log Level: Error
The chassis code monitor (dm_chassis) cannot run on this machine. Either the machine does not generate chassis logs, or the machine
is not supported by dm_chassis. Currently, the following set of machines are supported by dm_chassis:
superdome
S-class
-------------------End Event-----------------------------------------Start Event--------------------
User event occurred at Fri Nov 2 00:09:59.380906 2007
Process ID: 3641 (/usr/sbin/stm/uut/bin/.../ha_disk_array) Log Level: Error
EMS Returned an Error Code in the get message loop. (0)

[Andrew Merritt_2]

Hi John,
I can answer 1 and 3.

1) What's the parent of the defunct process? I.e. which process has pid 2945? If it's ia64_corehw, then this is normal. The parent forks a process once a minute, and cleans it up at the same rate, so that most of the time, assuming the child has finished its job and exited, it shows as defunct. This does not cause any problems.

2) You'll need to identify what's actually using up the space.

3) What's the interval on restarts? Is it 5 minutes? There is a known problem with SFM (SysFaultMgmt) which attempts to restart monitors that are not appropriate for the current hardware, so the monitors (correctly) exit. The main problem this causes is that other log messages might be missed. This is a known problem and should be fixed in a future release of SFM.

Andrew