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!