Re: [gentoo-user] System reboot

[Dale]

Rich Freeman wrote:
> 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.
>


I've seen kernel panics in the past.  Keep in mind, different panics can
behave differently but in the past, I got a console type screen with
some weird error messages.  Those are what I usually see.  This tho, it
was as if the power off button was pushed and held down.  The system
didn't reboot, it powered off.  I was asleep but it did beep, which is
what woke me up.  Generally in the past when I've seen something like
this, it either goes to the console and sits there until I hit reset or
just reboots.  This is the first time I've seen my system poweroff like
this.  This is what has me curious. 

My BIOS is set to remain off in the event of a power failure, which
shouldn't reach it with a power glitch or even short term power outage
due to the UPS.  However, if power fails and it does a shut off, it is
set to remain off.  This is what makes me think power supply.  It's not
that old but that doesn't rule it out either.  I've read about bad out
of the box units before.  Thing is, that is what it sort of acts like. 

My power supply is a 650 watt unit.  It can power over twice what I
pull.  When I built this rig, it could power up three times what I
pull.  Keep in mind, I'm measuring not only the puter but also the
monitor, speakers, modem and router as well.  That wattage is from the
UPS itself.  I try to allow for a lot of head room power wise to
compensate for that turn on surge when several drives and fans are
spinning up.  I've got five hard drives, three 230MM fans and a 140MM
fan just for the case.  Then comes the CPU etc.  I haven't calculated
the surge or anything but I figure it is a good bit more than what it
pulls when already running. 

It may be that this has to happen a few times to see if anything can be
narrowed down.  Maybe it will do it while I'm sitting at it next time
and I can see from start to finish what it is doing.  May help, may
not.  One reason for the thread, tips on what to look for.  A good tip
could come in handy.  ;-)  Plus, I thought there may be another log I
wasn't aware of to look at. 

Thanks.  Gives me things to think on. 

Dale

:-)  :-)