CentOS - Oct 2017 - systemctl reboot -- server not accessible after reboot

On Sat, Oct 14, 2017 at 6:24 PM, Jonathan Billings <billings at
negate.org> wrote:
>
> When you say that the monitor is plugged in, and the server is
unresponsive, does that mean that the monitor doesn?t even come active?  That
sounds like it might have crashed the kernel in a way that the display isn?t
showing.
>
> You could set up kdump to catch that.  You could also set up a persistent
journal (create /var/log/journal) and try again, then when you manually power it
up, check to see if anything was logged in the journal.
>
> If the system?s keyboard is plugged in, you could try using the magic sysrq
keys to get it to do something.  (see
https://en.wikipedia.org/wiki/Magic_SysRq_key )
> Try ?c? to initiate a crashdump to force kdump to record a kernel dump,
then you can examine the active processes.  ?k? or ?g? might clean up the
display if it?s bad.
>
> Also, remote syslog is always helpful for these kinds of situations,
although if the network is down when it crashes then it won?t be as helpful,
which is why I suggest looking at the journal.
>
> --
1. Monitor is on but screen is blank.
2. kdump logging --- i'll follow up on that.
3. remote syslog --- i'll need to do some more rtfm. I looked at
/var/log/anaconda/syslog but I can't tell which boot-up I was looking
at.  Seemed like everything was normal...identifying naming locating
hardware/devices....systemd services starting and running.

Thank you for your thoughtful responses.
Very much appreciated.
Good points to follow up with.
Kind regards,
Mike

It turns out kdump.service is already enabled on the server and
/etc/kdump.conf settings would report any kernel crash/error items to
/var/crash.
The /var/crash file/folder is empty.
It leads me to think the kernel is not crashing; however, I could be wrong.
I'll need to perform another test "systemctl reboot" from remote
ssh
session and check it one more time.