• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 349
  • Last Modified:

Redhat Unscheduled Reboot


I have had an unscheduled reboot and would like to know the best place to start to find out what happened. am aware "messages" and "dmesg" is a good start but other options would be great.

p.s. not hardware - I have checked
1 Solution
If your hardware includes logs, check whether there was a power related event.
ps1 lost power, ps2 lost power.
if you have kdump configured you can check to see whether the reboot was caused by a kernel panic and using the kdump file, you can look at exploring what happened.
If you log sudo data into its own file, check that.
Also check using the "last" command and see the last column or so for a message (sometimes it can say "crash" or "reboot" etc..)
lm-exchangeAuthor Commented:
Hi, I checked "last" and it did list Reboot, matched time it happen too.
Is there a way how to find out what actioned the reboot based on the information pointing "reboot" listed in last output ?
Build your data science skills into a career

Are you ready to take your data science career to the next step, or break into data science? With Springboard’s Data Science Career Track, you’ll master data science topics, have personalized career guidance, weekly calls with a data science expert, and a job guarantee.

Your best bet is /var/log/messages. Check the time it was rebooted on this file. It depends also on what services your server serve. If it is an application based server check that application logs to see if it gives you clues though the chances are remote an application can force the system to reboot.
It should tell you the users who had sessions at the time, it could very well be an error that the person thought they were on a different server when they issued a reboot.
look at /var/log/secure if that is where you sshd logs to see who logged in before this reboot as well as who logged in immidiately after the system came back up. (i.e. user with admin rights mistakenly issued the reboot, and relogged in to make sure all was functional).
Also, make sure it isn't some cron job. We got nipped by unexpected reboots because we had a cron job set up as part of our automated patching. If a system was patched and rebooted on the 31st day of the month, anacron (which regards all months as having 30 days) would think the cron job was missed and re-run it.

Our solution was to disable anacron - it was designed for systems that aren't on all the time, or which switch back and forth between OSes (e.g. dual-boot), and which might need to "catch up". It is enabled by default in RHEL, but for always-on servers already running cron, using anacron is pointless.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

A proven path to a career in data science

At Springboard, we know how to get you a job in data science. With Springboard’s Data Science Career Track, you’ll master data science  with a curriculum built by industry experts. You’ll work on real projects, and get 1-on-1 mentorship from a data scientist.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now