In a well configured environment, "history" isn't going to be terribly useful -- admins should be using their own accounts and using sudo to execute commands as root.
In this sort of environment you want to look at your pam logs (/var/log/auth.log on debian-like distros, and iirc, /var/log/secure on RH-like). This gives you not only a list of what was run, but who ran it and when.
A reboot is the last thing you should be doing on a problematic box. A reboot should only be attempted if you're 100% sure that the problem can actually be solved by a reboot (for example in extreme cases a buggy kernel module might require a reboot, but even that's a very rare occurrence).
I've seen inexperienced sysadmins remotely rebooting a server only to discover that it won't boot up anymore because the original problem was that the server had run out of disk space.
That's a valid point; mention that one should not reboot until proven otherwise.
Same idea for services restart; don't do it unless absolutely needed. While it may be doing the trick in some cases it can also generate its own set of new false symptoms.
Take the example of :
- mysql is "slow"
- let's restart ! ...
- mysql init script has been puking dots (.) for the last 30 minutes on shutdown
Comments
One key thing missing imo. "history" can be a huge help. Even more so if there are multiple admins on call.
In a well configured environment, "history" isn't going to be terribly useful -- admins should be using their own accounts and using sudo to execute commands as root.
In this sort of environment you want to look at your pam logs (/var/log/auth.log on debian-like distros, and iirc, /var/log/secure on RH-like). This gives you not only a list of what was run, but who ran it and when.
LOL! My `history` says I use only `cd`, `ls` and `git`.
Shame for me ...
http://imgur.com/CBTrdJw [server linux box] http://imgur.com/tEjBtNY [development os x box]
This indeed a huge help, this is now updated.
I'm pretty sure there is also a whole bunch of other (less famous) commands that would and should be added.
And the infamous reboot?
A reboot is the last thing you should be doing on a problematic box. A reboot should only be attempted if you're 100% sure that the problem can actually be solved by a reboot (for example in extreme cases a buggy kernel module might require a reboot, but even that's a very rare occurrence).
I've seen inexperienced sysadmins remotely rebooting a server only to discover that it won't boot up anymore because the original problem was that the server had run out of disk space.
Yes, that's why I think the article should mention reboot.
That's a valid point; mention that one should not reboot until proven otherwise.
Same idea for services restart; don't do it unless absolutely needed. While it may be doing the trick in some cases it can also generate its own set of new false symptoms.
Take the example of :
- mysql is "slow"
- let's restart ! ...
- mysql init script has been puking dots (.) for the last 30 minutes on shutdown
- let's kill -9 it ! ...
- mysql db is corrupted ! Hurray!