Solution 1:

A couple places to start:

  • listening services (netstat) - this should, generally speaking, give you a decent idea of what's going on with the system.
  • /root/.bash_history (or that of other users, if they didn't use root) - whatever's been going on on the console will, ideally, be related to the purpose of the system.
  • /var/log - take a glance at the standard logs, and look for anything application related.
  • Installed packages - this is specific to the distribution of linux that they're running, but if the logs are there, take a look. /var/log/dpkg.log, /var/log/yum.log, etc.

Solution 2:

Hardly scientific I know but if you get permission from your management I'd consider pausing the VMs - you'll find out if they're important quicker that you'd think, if it stays paused with nobody complaining...well that tells you something else.

Seriously though you could spend a career trying to figure them out without every truly knowing everything they do. Pausing them may seem odd/draconian but in the absence of documentation I'm sure you could sell the idea to management, as a one-off at first to see how it goes anyway.

Solution 3:

I was surprised to see that the first answer suggested wasn't ps -ef, so I'll add it: if you want to know what a system is doing right now, read the process list, paying particular attention to what root is up to, and whether there are processes owned by conspicuously-named users (mysql, named, etc).

I'd then compare my process list against lsof run as root to see which processes are listening on the network, and which are holding open files. Typically this gives you a pretty good picture of the long-running processes on the box, which are commonly its main function.

Notable exceptions include mail - see local syslog and mailq for details on what's being processed by sendmail - and inted-type run-on-demand services, for which /etc/xinetd.conf is a good bet, at least for most recent Redhat-based Linuxes.

Hope that helps; let us know if you run into something in particular we can help identify!

Solution 4:

I would start by seeing what services are running... Then attempt to match those to what they are hosting. Do NOT under any circumstance power off what you have no idea it's doing as you could break what ever it is running an if its mission critical( if that is the route your dying to take, pause them)... You should also check to see if there any sort of documentation.