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
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
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
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
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
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
A related command that does similar but not quite identical
things is yum
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
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
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
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! :-).