| Article Index |
|---|
| Linux troubleshooting tools |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| All Pages |
Linux troubleshooting tools
When something goes wrong with your Linux-based system, you can try to diagnose it yourself with the many troubleshooting tools bundled with the operating system. Knowing about these tools, and how to effectively use them, can help you overcome many of the common problems on your system. Here's a list of some of the weapons in your arsenal against Linux problems.
Strace
When an application
you successfully compiled fails during run time, it usually gives
you an error. On a lucky day, the error message might contain
details of what went wrong, and give you clues about what to do to
fix the problem. But this is not what usually happens. Often, error
messages are obscure and of little help in figuring out what went
wrong. Strace can come in handy in such situations. This utility
traces the system calls a program uses during its run time. A
system call is a Linux kernel function that provides secure access
to a system's resources, such as memory, disk, and network.
Strace is easy to use -- just pass the name of the executable you
want to run as an argument to the strace application. As an
example, check out what output you get when you trace the following
simple "Hello, world!" program:
#include
int main()
{
printf("Hello, world! ");
return 0;
}
$gcc -o hello hello.c
$strace ./hello
execve("./hello", ["./hello"], [/* 94 vars */]) = 0
brk(0) = 0x804b000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7eff000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/tls/i686/sse2", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/tls/i686", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/tls/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/tls/sse2", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/tls", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/i686/sse2", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/i686", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib/sse2", 0xbf91d630) = -1 ENOENT (No such file or directory)
open("/opt/wx/2.8/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/opt/wx/2.8/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=186839, ...}) = 0
mmap2(NULL, 186839, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ed1000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
write(1, "Hello, world! ", 14Hello, world!
) = 14
exit_group(0) = ?
Process 6006 detached
In the above output, you can see that to run this simple program, a good number of system calls were made to open, read, write, close, etc. Notice that there were a large number of unsuccessful calls to open the libc.so.6 library. That's because the run time linker is looking in several places to find the library. The only successful call to open the library is when the linker looks for it in the /lib location, as shown by the line shown in bold letters in the output, where the open system call returns a value of '3,' which is an indication of successful opening. If we could somehow make the loader look in /lib first, we could save a lot of unsuccessful calls for the library search. And of course we can, by bringing the string /lib to the beginning of the environment variable LD_LIBRARY_PATH, which the run time linker uses to search for the libraries required by the running program.
$export LD_LIBRARY_PATH=/lib
The output of strace
can be quite unwieldy when it's dumped to the console. It is
common to redirect this text to a file by using the command's -o
option. Another common option is -p, or PID, which allows you to
connect to a running program and see its output. This is useful in
the case of long-running daemons which you cannot restart easily,
or which need to be monitored very rarely. A nice example of how
useful strace can get comes from a user who had installed
multimedia codecs, including libdvdcss, which allowed him to play
encrypted DVDs. But when he tried to use his movie player to play
DVDs, he got strange errors. On tracing the movie player with
strace, he figured out that the run time linker was looking in the
wrong places for the installed codecs. After searching for the
required library and putting it in a directory where the linker
could find it, he was able to run the movie player to play his
DVDs.
