Re: [gentoo-user] System reboot

[Rich Freeman]

On Sat, Dec 15, 2018 at 10:54 PM Dale <rdalek1967@×××××.com> 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