If all you have is a hammer,
everything looks like a nail.

The Big Hammer is indeed an excellent tool to use on Linux, but to discover what needs hammering, more subtle tools are often needed:

• google Without Google, Linux itself would be impossible. Google is essential for finding information on Linux (or anything else, really). However, you might find you can get better results with the Advanced Google Search. Because Linux changes so much, vast numbers of Google hits will return obsolete information. Restricting the date range to the last year or even last month can help find accurate information.

  The site specific Google search is also useful for explicitly searching mailing list archives, wikis, forums, etc. Lots of these things have their own search tool, but none of them ever come close to providing results as accurate as Google (unless they just use google, of course).

  For instance you can search this site with google.

• /usr/share/applications/ This directory is where virtually all of the menu entries for starting programs from launchers resides. You often want to know the name of a program, but linux developers are apparently horrified by the prospect that you might actually find out the real name (perhaps they are related to Rumpelstiltskin).

  Or maybe you can't even remember what the name you are looking for was, you just know it had something to do with (for example) sound or audio.

  Whatever the reason, you can probably find the program by grepping the files in /usr/share/applications/ like this:

  cd /usr/share/applications/
  grep -n -i -m 1 -r search-target .

  The -m 1 option is particularly useful since the desktop definition files usually contain the name many times in different languages, and you often get zillions of matches in the same file. This option stops after finding 1 match in each file.

  Once you find the file you are looking for, there will be a line in it that begins with Exec=. The remainder of that line is the actual program run by the menu entry, so now you know the real name.

• strace is a specialized debugger which will tell you all about the system service calls made by a program. If it hangs for a long time, you might be able to find out why (see Claws-mail case study). If it is insisting on reading some saved configuration that is all wrong, you can perhaps find the name of the file it opens and remove it to clear the bad saved config (the option -e trace=file is quite useful for examining the files a process uses).

  If it is really running other programs to do all the work, you can add the -f option to follow forks and see the system service calls of the entire process tree.

• top, ps If your system is slow, the first tools to check are top and ps. They can tell you what is running, how much memory it is using, etc.

  top can be asked to sort by different fields or filter the list of processes.

  Once you find an offending process, some of the remaining tools can tell you just what the heck it is.

• /proc, /sys The /proc and /sys filesystems are special virtual filesystems exposing information about the innards of your system and the processes and devices on it. They are way too complex to go into detail here, but a couple of the /proc tricks are useful to mention.

  If you have found a process bogging down your system, you can find the real name of the executable via: ls -l /proc/pid/exe and you can find what files it has open with: ls -l /proc/pid/fd

• rpm (on systems that use rpm packages such as redhat and fedora) can provide a lot of useful information about files installed on your system.

  For instance, if you used /proc to discover that an executable named /usr/bin/hog is the one clobbering your system, the command rpm -q -f /usr/bin/hog will tell you the name of the package that installed it. If you add the -i option to that command, it will print a complete description of the package which usually inculdes a URL where you can go to read even more.

  A little known fact: The source rpm described in the -i output is also the name of the component to use when you want to submit a bug about a program (at least for the redhat bugzilla system).

• yum is the layer on top of rpm that can do more complicated queries about packages. It knows not only about packages that are installed on your system, but also about packages that could be installed. For instance, if you are trying to build some tool from a source tarball, and it is trying to include some file that doesn't exist, you can try yum whatprovides /usr/include/somefile.h

  A related command that does similar but not quite identical things is yum search.

  Other utilities that use yum are debuginfo-install for downloading and installing the debug info packages so you can do symbolic debugging of programs and libraries on your system.

  There is also yumdownloader that simplfies the task of doing things like downloading the source rpm for some program.

• strings is a dead simply program to find printable string in a executable or library, but the simplest programs can often turn up just what you need to know.

  Names of files that the program opens, or help strings or error message strings can often give you some hints about what is going on.

• gconf, dconf are tools for accessing the idiotic linux clone of the windows registry. The Gnome developers apparently invented gconf because they wanted one of everything windows had, regardless of the fact that the windows registry is the most reviled invention in the history of computing.

  Then they wanted everyone else to start using it, but because it starts with a 'g' which stands for gnome, no one else would use it, so they are now moving to dconf, which, the theory is, everyone will gleefully adopt because it doesn't start with a 'g' (at least that's the story as near as I can tell :-).

  In any case, the GUI tools gconf-editor and dconf-editor often allow you to find and tweak otherwise hidden settings for various programs. (Especially tweaks to the user interface since every time the Gnome devs improve things, they can't be bothered to port all the little settings apps they used to have, so it is simpler to just get used to doing tweaks at the loweset level.)

• dbus-monitor allows you to watch dbus messages zooming around on your system. Since more and more tools are using dbus to communicate with background daemons, this can be a valuable tool for discovering what is going on behind your back.

  You can also arrange for hooks to run on various dbus events using tools like my xdbusd utility.

• udevadm allows you to monitor and query the magic that is udev. Plugging in new hardware (from USB to e-sata and beyond) all generate udev events which tools can listen for.

  Tools can also query udev to get lists of devices (like my mountie tool.)

• wireshark allows you to monitor your network activity.

  If you think tools might be “phoning home”, this is probably the way to find out. If you just wonder why your network activity monitor is flashing so much, this allows you to discover the details.

• nstar is a toolset available from Concurrent Computers, and this is a shameless plug because I work there, and spend much of my time on the NightView debugger.

  The NightStar Tools are available as a free download for noncommercial use. Try it! You'll like it! :-).