5.0 shuts down

[Lexus45]

Hello all.

I have a test OpenBSD 5.0 i386 box on a pretty moderate hardware:

cpu0: Intel(R) Celeron(TM) CPU 1300MHz ("GenuineIntel" 686-class) 1.31 GHz

It rebooted twice during last days. I think it's something wrong with the hardware. Before, it has been up for 2 or 3 weeks until I rebooted it manually.

Is there any log file which can show the reason of reboot? I looked through all logs from /var/log , only /var/log/messages shows some info:

/var/log/messages:Apr 10 09:23:44 voip reboot: rebooted by lexus

"lexus" is my username. And this case is the case when I rebooted the system manually. But there are no any entries about unexpected reboot. (On the other hand it would be strange, if the system writes some logs before the reboot, whis is unexpected, isn't it? :-) )

The box doesn't have an UPS attached, but we practically don't face any froblems with the electricity. But I'm not sure at all, so, maybe there was a tiny brake with the electric power, and it'll give the answer to my question.

In fact, the system could have been not rebooted buth halted. I just played with the BIOS options to power the box automatically on, when AC is in.

The problem is not critical for me, but still it will be better to know if some appropriate log file exists.

[ocicat]

Originally Posted by Lexus45

Is there any log file which can show the reason of reboot?

None of which I am aware.

Your description sounds like this is intermittent in which case I then question the memory. sysutils/memtest86+ is available as a package. You may want to consider testing. If you do, let it run for several hours. Anything less is insufficient.

You will also find the same application at http://www.memtest.org.

[jggimi]

If this were a power-down rather than a reboot then there would be a possibility of a misreading of a temperature sensor or incorrect fan management under ACPI. But reboots without kernel involvement indicate a hardware problem. By default, OpenBSD's kernel should drop to ddb(4) in the event of a kernel panic or other crash(8).

The memory testers can prove if there is a memory problem; unfortunately they cannot disprove the contrapositive -- they may not disclose a problem.

If memory tests after a number of hours (I prefer 8+ hours, 24+ hours when possible) do not disclose a problem, consider stress tests.

Stress testers typically work by raising CPU temps and power draw, and those can disclose a variety of hardware problems. (They also run the risk of adding heat damage if thermal controls, such as airflow, are not functioning properly.)

On OpenBSD, there are two stress testers available:

1. sysutils/stress
2. building OpenBSD userland from source code