I'd be willing to accept that there's something wrong at a system level, except it runs for weeks at a time without trouble between this happening. If something were so fundamentally flawed, don't you think it would show up sooner?mikb wrote: ↑Sun Feb 18, 2024 7:20 pm Just a theory, but maybe things quitting/exitting is a sign of something fundamentally wrong -- so wrong, in fact, that syslogd/klogd or the equivalent part of systemd ... is exitting too. This means that the normal path of messages (that would be captured, filtered and filed according to your rules) is gone.
Kernel is still running and still has stuff to say. So, last resort, spit them onto the physical console.
"Remote logging" might turn into a camera pointed at the monitor at this rate
Problem with pointing a camera at the screen is that this system is connected via a KVM & the vast majority of the time, my PC is what's shown on the screen. I'd also have to set up another ZoneMinder system / camera, which at this time I'm somewhat doubting my ability to make it reliable. (Really never thought I'd think, much less say, something like that...
) Might be able to find a gizmo to clone the display to another monitor & set up another screen for the camera to watch; will keep it in mind if the remote logging isn't helpful.Searches finally uncovered someone else getting these same type of error messages, only with Arch at https://bbs.archlinux.org/viewtopic.php?id=241005 - he was having problems with his system not resuming from hibernation. Doesn't appear that these messages caused any issues. Solution ended up being to unload the sound modules, hibernate, then reload them after the system came back up. Wayback Machine reveals that the dead link in that thread was specifically about hibernation problems / troubleshooting and not really applicable in my circumstances.
An old machine is currently installing for remote logging as I write this. (Never configured remote logging before, so it'll be interesting.) Here's the local syslog from when it died the night of February 15. It's complaining about the missing events, then there's a chunk of binary data in the log when it died, then nothing until I forcibly rebooted it on the 16th when it shows the boot messages & starts complaining about missing events again. Am I missing something?
PasteBin Link because it's too big for the forum, Password is ZoneMinder - https://pastebin.com/JziwFUWs
(Something odd I noticed when chopping up the original 7.8 gig syslog is that the first 4 inputs [0-3] are being forced to type 42 as they should be from the module configuration, but the last 4 [4-7] are autodetected as type 98. The inputs seem to work... wonder if this might be the cause of something.
)I really appreciate the pointers and feedback... trying to wrap my head around this and come up with a plausible theory that fits the observed behavior is sending my brain into an uncontrolled recursion loop.
) I changed the bttv configuration back to card type 42, added 4 more log suppression rules, and rebooted... and it still refused to work. Discovered that in one of the numerous reboots, the BIOS swapped the device nodes of the two drives - the SSD boot drive was now /dev/sdb & the HDD storage drive was /dev/sda. (References to the UUID in /etc/fstab obviously didn't work anymore after I re-created the new file system with a bigger inode area, so I had just changed it to reference /dev/sdb1 instead of the UUID. Never seen a system change device nodes like that before...) Looked up how to get the UUID of the file system (blkid /dev/sda1) and changed fstab to reference the UUID instead of the device node. Rebooted, corrected the typo in the UUID, rebooted again, and both file systems mounted properly. Unfortunately, ZoneMinder still wasn't working.
