On Sat, Dec 15, 2018 at 10:54 PM Dale <[email protected]> wrote: > > I checked the messages log. Before with the memory hogging Dolphin it > had logged the problem. Today, it shows this: > > > Dec 15 20:40:01 fireball CROND[30668]: (root) CMD (/usr/lib64/sa/sa1 1 1) > Dec 15 20:50:01 fireball CROND[1532]: (root) CMD (/usr/lib64/sa/sa1 1 1) > Dec 15 21:00:01 fireball CROND[5513]: (root) CMD (/usr/lib64/sa/sa1 1 1) > Dec 15 21:01:01 fireball CROND[5718]: (root) CMD (run-parts > /etc/cron.hourly) > Dec 15 21:08:34 fireball syslog-ng[4370]: syslog-ng starting up; > version='3.17.2' > Dec 15 21:08:34 fireball /usr/sbin/gpm[4400]: *** info > [daemon/startup.c(136)]: > Dec 15 21:08:34 fireball /usr/sbin/gpm[4400]: Started gpm successfully. > Entered daemon mode. > > > As you can see, it went from running a normal cron job to me booting > back up. I don't see any error at all. Not even one electron.
This is pretty typical if you aren't taking special steps to log this sort of thing. There are a couple of ways the kernel can crash: 1. OOPS/BUG - these are semi-recoverable errors. I believe they can get logged unless they occur in a manner that disrupt your userspace logger, vfs, filesystem, or disk. If the error happens in one of those subsystems then your filesystems will stop syncing and it won't be logged normally. 2. PANIC - these are unrecoverable and are NOT logged. When the kernel PANICs it halts all disk IO and just about everything else. This is to prevent damage to anything already written on disk. You don't want a corrupt OS trying to write to your disk - that makes a bad situation MUCH worse. It would be like sending a drunk surgeon into the operating room to fix up a trauma patient. 3. Hardware reset. This isn't a kernel issue but I'll toss it in. If your CPU gets a reset signal it forgets it was ever running linux and starts executing the firmware as if it had been freshly powered on. There is no opportunity to capture anything. Only way to log something like this is hardware-level monitoring. Issues #1-2 CAN be logged, but not conventionally. There are few routes for this: 1. Remote console logging. Serial and network are the two main options for this. If you have a hardware serial port you can capture its output and any kernel errors will be output to these (just the text/backtrace/etc). A network console is very easy to set up if you have a remote host that can run netcat on the same LAN: https://www.kernel.org/doc/Documentation/networking/netconsole.txt 2. Recovery kernel. Gentoo doesn't have tooling for this but you can follow https://wiki.gentoo.org/wiki/Kernel_Crash_Dumps . Disclaimer - I haven't done this in ages so it could be dated in parts. If the kernel panics then it will run the recovery kernel, which boots in a clean state and dumps the old kernel's RAM to disk for subsequent analysis. #1 gets the job done most of the time, but #2 is more thorough. If you have a host that is tending to reset you should consider network logging as a starting point - it is easy to set up. I'm not sure why your UPS display is coming on. It might be some kind of spurious data on the USB port if it is connected. It might be a result of something the PC is doing. It is also possible it is due to a brownout or other power issues going into your house, but if your UPS is in good shape and not overloaded then it should be shielding your PC from the effects of these. A PC power supply issue sounds plausible. I've had my CP UPS flicker its display and a light might flicker a bit at the same time, but the PC was unaffected. I'll also note that these kinds of transient issues are often mitigated by having a good quality PC power supply that is not overloaded, and that this probably also helps with any latency in the UPS switching in. If your PC power supply is strained to the point of breaking then any transients in the input supply are going to get through to the output rails. This is one of those areas where spending an extra $30 on your build can make a significant difference. -- Rich
