1847018 Members
4540 Online
110258 Solutions
New Discussion

Untraceable Reboots

 
Ralph Grothe
Honored Contributor

Untraceable Reboots

 
Madness, thy name is system administration
6 REPLIES 6
BFA6
Respected Contributor

Re: Untraceable Reboots

Hi,

Is there anything in /var/tombstones? Have a look at timestamp on ts99

Regards,

Hilary
T G Manikandan
Honored Contributor

Re: Untraceable Reboots

Also do check any single line message in the OLDsyslog.log as "memory full".

When the RAM is full with no swap space,might trigger a similar condition.

Revert
Darren Prior
Honored Contributor

Re: Untraceable Reboots

Hi,

I'd suggest you run check_patches to get a more comprehensive check of your patching situation. Make sure that you have PHCO_22044 or a newer check_patches patch first though!

I did notice that one of your patches (PHSS_20146) is actually a workstation firmware patch - which makes me wonder how the other patches have been applied...

regards,

Darren.
Calm down. It's only ones and zeros...
john korterman
Honored Contributor

Re: Untraceable Reboots

Hi Ralph,
did you capture anything interesting from dmesg before the server hit the ground? If the server does this often, you could try to setup a cronjob for writing the output of dmesg to a file. Perhaps something interesting would appear.

regards,
John K.
it would be nice if you always got a second chance
melvyn burnard
Honored Contributor

Re: Untraceable Reboots

well I would think that you have had eihter:
A power failure or
Someone issueing the reboot -q command or a Hardware failure in something like a system board or power supply.
Get htese checked out if I were you.
My house is the bank's, my money the wife's, But my opinions belong to me, not HP!
Ralph Grothe
Honored Contributor

Re: Untraceable Reboots

Hilary,

as I wrote, ts99 got a recent timestamp which corresponds to when the machine ran the rc scripts

# ll -rt /var/tombstones/
total 84
-rw-r--r-- 1 root root 6864 Aug 29 2002 ts94
-rw-r--r-- 1 root root 6864 Sep 15 2002 ts95
-rw-r--r-- 1 root root 6864 Dec 30 13:45 ts96
-rw-r--r-- 1 root root 6864 Mar 24 16:40 ts97
-rw-r--r-- 1 root root 6864 Mar 26 11:03 ts98
-rw-r--r-- 1 root root 6864 Mar 28 15:58 ts99


Contents of all errors, chassis codes, registered is all set to 0

T.G. M.,

no there are no occurrances of /memory/i in OLDsyslog.log

Darren,

thanks for the advice to run check_patches.
The logfile it created gives me sufficient hints to follow first

# check_patches -imops
Obtaining information on installed patches
Checking for invalid patches
Checking for ar(1) patches
Checking object module checksums for active patch fileset 664 of 664
Checking patch filesets for active patch 380 of 380
Checking state for patch fileset 1090 of 1090
Checking patch_state for patch fileset 1090 of 1090
RESULT: Problems found, review /tmp/check_patches.report for details.


Melvyn,

this box is no longer under HW maintenance contract, but I will check if I can find myself sufficient evidence that power supply is ok.
Madness, thy name is system administration