Server has been running fine for years until about a week or so ago when I noticed the server array was offline after an "unclean shutdown" mind you I don't ever shutdown my server. The only change software wise is I finally updated to 7 after putting it off for a long time and I uninstalled proftp when moving to 7. I have no diagnostic logs being saved (last diagnostic zip is from 2022) but I did enable syslogging.

The other issue I've noticed since upgrading to 7 is connecting via the tower.local url is much slower for some reason than just connecting with the url. It takes a long time to connect ever since going to 7 which seems weird.

Is there anything in syslog I need to filter out for privacy if I post the logs online?

Thank you.

EDIT I also ran a full memtest and had zero errors after all passes. My server is also on a sinewave ups that has reported no outages

syslog syslog-previous

Edited June 23, 20251 yr by Tenno23

Mirror the syslog to flash, without logs it's just spitballing. You can try just running it as a basic NAS for a few days to see if it continues to spontaneously shut down. And never rule out a power supply just deciding to knock off, either.

Just now, Michael_P said:

Mirror the syslog to flash, without logs it's just spitballing. You can try just running it as a basic NAS for a few days to see if it continues to spontaneously shut down. And never rule out a power supply just deciding to knock off, either.

I have syslog's mirrored. Do I post the previous one? Hopefully it isn't the power supply but I did consider that. Since it happened directly after upgrading to 7 its hard not to assume something with that upgrade is what caused it.

Need one more recent than 2022 lol, it'd need to be one from a 'crash'

11 minutes ago, Tenno23 said:

its hard not to assume something with that upgrade is what caused it.

In my experience it's just as likely to be a coincidence. Random shutdowns/reboots are usually hardware related, and if nothing's logged I'd start with the power supply

Just now, Michael_P said:

Need one more recent than 2022 lol, it'd need to be one from a 'crash'

In my experience it's just as likely to be a coincidence. Random shutdowns/reboots are usually hardware related, and if nothing's logged I'd start with the power supply

No I have current syslog's but no diagnostic zips. I have syslog and syslog-previous which seems to be the log up till a crash. It hasn't made any diagnostic zips since 2022.

Just now, Tenno23 said:

I have syslog and syslog-previous which seems to be the log up till a crash

Post those

Just now, Michael_P said:

Post those

added to OP

Looks like both of those were after the reboot from the crash and don't contain anything during or before, best advice I can give at the moment is to try running it as a NAS for a few days, run memtest to rule out RAM, then start throwing parts at it starting with the PSU.

1 minute ago, Michael_P said:

Looks like both of those were after the reboot from the crash and don't contain anything during or before, best advice I can give at the moment is to try running it as a NAS for a few days, run memtest to rule out RAM, then start throwing parts at it starting with the PSU.

The syslog-previous is before the crash. This is how all my logs look after it happens (it always happens when I'm not using the server it has never happened when content is being watched from plex or anything)

From syslog-previous it crashed somewhere from 23:07 and I brought it back online at 00:29 the following day from syslog. Why are you saying syslog-previous is from before the reboot?

Every syslog-previous I get ends around the time the server crashes and the times logged are all before the crash.

Edited June 23, 20251 yr by Tenno23

3 minutes ago, Tenno23 said:

Why are you saying syslog-previous is from before the reboot?

the one in your OP starts at Jun 22 21:35:51 as the system was booting

Just now, Michael_P said:

the one in your OP starts at Jun 22 21:35:51 as the system was booting

Why wouldn't the logs include booting information? It booted at 2100 and crashed after 2300 and then booted again at 0000 the syslog-previous is the previous log from before a new bootup everything from bootup at 2100 until it no longer was recording information due to a crash at 2300.

In sys previous, there's the 3 entries at the end not related to startup, and nothing in there to suggest it was software related

Just now, Michael_P said:

In sys previous, there's the 3 entries at the end not related to startup, and nothing in there to suggest it was software related

That's how all the previous logs have looked. Nothing common among them. We were gone all day yesterday and the server was mostly idle.

The only other change I made recently is turning off netbios in smb since I saw something about it causing issues with ftp. I've reenabled netbios in smb on the latest reboot. I've also attempted stopping docker applications one at a time to see if the crash stops.

Memtest has been fine but if it crashes again after changing the netbios setting back I'll put in a backup psu and see what happens.

Hardware gremlins are the hardest to track down. And just a thought, make sure your batteries are still good in the UPS, too

Just now, Michael_P said:

Hardware gremlins are the hardest to track down. And just a thought, make sure your batteries are still good in the UPS, too

UPS is actually pretty new (bought it late last year to protect server and all my network cabinet stuff) still reports 100% battery health and fully charged.

1 minute ago, Tenno23 said:

still reports 100% battery health

They run pretty loose in their definition of healthy lol, mine usually say 100% health too, until the power blinks and it shuts off the rack.

2 minutes ago, Michael_P said:

They run pretty loose in their definition of healthy lol, mine usually say 100% health too, until the power blinks and it shuts off the rack.

Ah well nothing else connected to it has lost power and I actually just had a crash while I was in the room looking at the ups. The other hardware running on it all have more than a month of uptime and no issues.

I'll probably pull the server and check the psu now.

Last logs were these entries:

Jun 23 09:00:47 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update

Jun 23 09:29:04 Tower kernel: docker0: port 6(veth5c21fcc) entered disabled state

Jun 23 09:29:04 Tower kernel: veth421c45c: renamed from eth0

Jun 23 09:29:05 Tower kernel: docker0: port 6(veth5c21fcc) entered disabled state

Jun 23 09:29:05 Tower kernel: veth5c21fcc (unregistering): left allmulticast mode

Jun 23 09:29:05 Tower kernel: veth5c21fcc (unregistering): left promiscuous mode

Jun 23 09:29:05 Tower kernel: docker0: port 6(veth5c21fcc) entered disabled state

Jun 23 09:29:05 Tower kernel: docker0: port 6(veth49d4bd4) entered blocking state

Jun 23 09:29:05 Tower kernel: docker0: port 6(veth49d4bd4) entered disabled state

Jun 23 09:29:05 Tower kernel: veth49d4bd4: entered allmulticast mode

Jun 23 09:29:05 Tower kernel: veth49d4bd4: entered promiscuous mode

Jun 23 09:29:06 Tower kernel: eth0: renamed from veth8ad5358

Jun 23 09:29:06 Tower kernel: docker0: port 6(veth49d4bd4) entered blocking state

Jun 23 09:29:06 Tower kernel: docker0: port 6(veth49d4bd4) entered forwarding state

Jun 23 09:29:24 Tower kernel: docker0: port 5(veth9231b47) entered disabled state

Jun 23 09:29:24 Tower kernel: vethcc6bd9a: renamed from eth0

Jun 23 09:29:24 Tower kernel: docker0: port 5(veth9231b47) entered disabled state

Jun 23 09:29:24 Tower kernel: veth9231b47 (unregistering): left allmulticast mode

Jun 23 09:29:24 Tower kernel: veth9231b47 (unregistering): left promiscuous mode

Jun 23 09:29:24 Tower kernel: docker0: port 5(veth9231b47) entered disabled state

Jun 23 09:29:25 Tower kernel: docker0: port 5(veth5052c84) entered blocking state

Jun 23 09:29:25 Tower kernel: docker0: port 5(veth5052c84) entered disabled state

Jun 23 09:29:25 Tower kernel: veth5052c84: entered allmulticast mode

Jun 23 09:29:25 Tower kernel: veth5052c84: entered promiscuous mode

Jun 23 09:29:26 Tower kernel: eth0: renamed from vethd24050e

Jun 23 09:29:26 Tower kernel: docker0: port 5(veth5052c84) entered blocking state

Jun 23 09:29:26 Tower kernel: docker0: port 5(veth5052c84) entered forwarding state

Jun 23 09:30:24 Tower kernel: docker0: port 1(veth66d38cf) entered disabled state

Jun 23 09:30:24 Tower kernel: veth9bbbf06: renamed from eth0

Jun 23 09:30:24 Tower kernel: docker0: port 1(veth66d38cf) entered disabled state

Jun 23 09:30:24 Tower kernel: veth66d38cf (unregistering): left allmulticast mode

Jun 23 09:30:24 Tower kernel: veth66d38cf (unregistering): left promiscuous mode

Jun 23 09:30:24 Tower kernel: docker0: port 1(veth66d38cf) entered disabled state

Jun 23 09:30:25 Tower kernel: docker0: port 1(veth29e0f67) entered blocking state

Jun 23 09:30:25 Tower kernel: docker0: port 1(veth29e0f67) entered disabled state

Jun 23 09:30:25 Tower kernel: veth29e0f67: entered allmulticast mode

Jun 23 09:30:25 Tower kernel: veth29e0f67: entered promiscuous mode

Jun 23 09:30:26 Tower kernel: eth0: renamed from vethafbfa67

Jun 23 09:30:26 Tower kernel: docker0: port 1(veth29e0f67) entered blocking state

Jun 23 09:30:26 Tower kernel: docker0: port 1(veth29e0f67) entered forwarding state

Edited June 23, 20251 yr by Tenno23

Figured out my problem. Somehow the psu cables got pinched somewhere when I went into the system recently to check a fan positioning. Panels off and no more issues.