Hi,
I'm trying to work out why a reboot is happening.
line power is fine. PSU is fine.
There's no coredump.
Nothing in /var/log/messages console.log all.log or daemon.log
Is there a thing I can set somewhere which when enabled will
capture why a system reboots?
thnx
--
The "boot" command will give you a vague description like "shutdown" or "crash".
If a crash was the cause then maybe your system isn't configured to make
core dumps. I suggest forcing a crash with "sysctl debug.kdb.panic=3D1" while you watch the screen to see what happens.
On Thu, Oct 16, 2025 at 7:35=E2=80=AFAM void <void@f-m.fm> wrote:
Hi,
I'm trying to work out why a reboot is happening.
line power is fine. PSU is fine.
There's no coredump.
Nothing in /var/log/messages console.log all.log or daemon.log
Is there a thing I can set somewhere which when enabled will
capture why a system reboots?
thnx
--
On Thu, Oct 16, 2025 at 8:12=E2=80=AFAM Alan Somers <asomers@freebsd.org>=wrote:
The "boot" command will give you a vague description like "shutdown" or
"crash".
boot command? I don't have this on my system. How do yo uget that?
IIf a crash was the cause then maybe your system isn't configured to make
core dumps. I suggest forcing a crash with "sysctl debug.kdb.panic=3D1"
while you watch the screen to see what happens.
Yea. If it is a reboot, and crash dumps are enabled, and there's nothing
is in /var/log/messages, you have limited options.
If there's a BMC, and it speaks IPMI, there might be something in the IPM=
log if it was hardware triggered (ipmitool sel list):
1 | Pre-Init |0000001024| Processor #0xe4 | Presence detected |
Asserted
2 | Pre-Init |0000000000| System Event | OEM System boot event | Asserted
3 | Pre-Init |0000000001| System Event | Timestamp Clock Sync |
Asserted
4 | 04/17/23 | 16:07:49 MDT | System Event | Timestamp Clock Sync | Asserted
5 | 04/17/23 | 16:11:12 MDT | OS Boot #0x22 | boot completed - device
not specified | Asserted
6 | 04/17/23 | 16:20:42 MDT | System Event | OEM System boot event | Asserted
7 | 04/17/23 | 16:23:16 MDT | System Event | OEM System boot event | Asserted
8 | 04/17/23 | 16:28:44 MDT | System Event | OEM System boot event | Asserted
9 | 04/17/23 | 16:30:25 MDT | OS Boot #0x22 | boot completed - device
not specified | Asserted
...
(oh my, I need to clear my log)
Warner
On Thu, Oct 16, 2025 at 7:35=E2=80=AFAM void <void@f-m.fm> wrote:
Hi,
I'm trying to work out why a reboot is happening.
line power is fine. PSU is fine.
There's no coredump.
Nothing in /var/log/messages console.log all.log or daemon.log
Is there a thing I can set somewhere which when enabled will
capture why a system reboots?
thnx
--
Yea. If it is a reboot, and crash dumps are enabled, and there's nothing is >in /var/log/messages, you have limited options.
If there's a BMC, and it speaks IPMI, there might be something in the IPMI >log if it was hardware triggered (ipmitool sel list):
1 | Pre-Init |0000001024| Processor #0xe4 | Presence detected |
to make core dumps. I suggest forcing a crash with
"sysctl debug.kdb.panic=1" while you watch the screen to see what happens.
Hi,ens.
On Thu, Oct 16, 2025 at 08:12:10AM -0600, Alan Somers wrote:
to make core dumps. I suggest forcing a crash with
"sysctl debug.kdb.panic=3D1" while you watch the screen to see what happ=
Not sure what this would do, apart from crash the machine immediately.
The problem, when it happens, is it's like power reset.
Ideally what I guess needs to happen is that the problem (whatever is
causing it) needs to crash to debugger or and/or make a crash dump
before completely exiting. Do you think enabling WITNESS and friends
may help?
--
Not sure if it helps in this case or not, but If you capture smartctl
info regularly, you can some times infer from the disk power cycle
count and power on hours if the box rebooted due to a power issue or
not.
I think power is a red herring though. This happens with
two different poudriere builder machines different UPSes different
locations.
The only commonality I can see so far is that both were building the same thing.
My nasty suspicious mind immediately wonders about system memory usage and >management (e.g. thrashing/page table load) during "the same thing".
On 10/17/2025 12:16 PM, void wrote:
On Fri, Oct 17, 2025 at 09:56:29AM -0400, mike tancsa wrote:
Not sure if it helps in this case or not, but If you capture smartctl
info regularly, you can some times infer from the disk power cycle
count and power on hours if the box rebooted due to a power issue or
not.
Good point.
I'm unsure how I'd distinguish between soft power cycle
and reboot though. The latter i'd expect to increment power cycle
count the former might but it might not.
In my case, I had it with a failing power supply or one that could not
deal with load. In my case showed power cycle counts increasing. Where
as, a shutdown -r now before
0{r-14mfitest}# smartctl -a /dev/ada0 | grep -i power
entering power-saving mode.
9 Power_On_Hours 0x0032 100 100 000 Old_age
Always - 40206
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 91
0{r-14mfitest}#
and after a reboot
s0{r-14mfitest}# smartctl -a /dev/ada0 | grep -i power
entering power-saving mode.
9 Power_On_Hours 0x0032 100 100 000 Old_age
Always - 40206
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 91
0{r-14mfitest}#
At least on my SuperMicro board shows the same power cycle count. Like
you said, probably does not apply in your case, but sometimes handy to
keep in the back pocket
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 54 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 12:23:06 |
| Calls: | 742 |
| Files: | 1,218 |
| D/L today: |
2 files (2,024K bytes) |
| Messages: | 183,176 |
| Posted today: | 1 |