Yes, it is possible to set nproc to equal 5. Commands such as SAM will warn you of this and won't let you make such a mistake. However, kmtune will allow you to set up such a configuration. After the next reboot, the operating system would panic and reboot, because it is unable to start enough system-critical processes. It is hoped that you have a backup kernel with which to boot the system and rectify the situation.
A2:
Many system utilities will assume that /stand/vmunix and /dev/kmem are, effectively, the same kernel image. When reporting system-level information, e.g., filesystem, swap usage commands will reference /stand/vmunix and /dev/kmem together in order to extract system-level information. If /stand/vmunix is significantly different from /dev/kmem , the requested information may not be available or may be corrupted/wrong, causing the system utilities to fail or report inaccurate information.
A3:
The tar command is perfectly innocent. The problem is with the rm command. While the syslog daemon is running, it will keep open the inode for the syslog.log file. Using the rm command simply removes the directory entry (the file is no longer listed with an ls/ll command) but will not free the inode until the daemon is stopped . The upshot is that we will not see any new syslog messages in the new touch 'ed syslog.log file. The syslog daemon will still be writing messages into the original syslog.log file, but we will not be able to access them, because we no longer have a directory entry referencing the still open inode. Restarting the syslog daemon will resolve the problem. In the future, we should simply use a command such as:
# > /var/adm/syslog/syslog.log
to return the syslog.log file to zero bytes in size .
A4:
Because this is a single error and the disk appears to be working, I would monitor syslog.log and STM diagnostics frequently and carefully . A single write error may be a "one-off" error that will never occur again. If the disk is in fact defective, we should see more and more similar errors being logged. As soon as I see more similar errors, I would report it to my local HP Response Center and request that an engineer diagnose whether the disk needs replacing.
A5:
A " panic: Data page fault " message could indicate a software problem. Hence, this would be a software- related crash, and we would place a software call with the local HP Response Center. However, we should also try to extract the tombstone directly from the processor(s). It may be that our system does not have the appropriate diagnostic software loaded in order to automatically store a tombstone after every reboot. We could use STM diagnostics (or work from the BCH interface) to extract a tombstone from the processor(s). If there was a valid tombstone that was time-stamped at the same time (approximately) as the crashdump, then we may want to flag this as a potential hardware problem with the local HP Response Center. I would also store the crashdump to tape immediately to ensure that we have a permanent record of this particular failure.
