Archiwum
- Index
- 08 Ernest Hemingway Mieć i nie mieć
- Burroughs, Edgar Rice Mars 08 Swords of Mars
- Laurie King Mary Russel 08 Locked Rooms
- Glen Cook Garrett 08 Petty Pewter Gods
- Brenden Laila Hannah 08 Znak Ognia
- Gordon Dickson Childe 08 The Chantry Guild
- Jacqueline Lichtenberg [Sime_Gen_08]_ _RenSime
- James Axler Earthblood 02 Deep Trek
- F Paul Wilson Deep As The Marrow
- viewcontentir
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- lafemka.pev.pl
[ Pobierz całość w formacie PDF ]
The -c switch counts the time, calls, and errors for each system call and summarizes this information when the
program exits. This information is helpful if you're debugging and you're not sure where to start, because it
will help you work out where the problem might lie.
Additionally, you can use -e trace=set to trace only the system calls you specify - for example, -e
trace=open,read,write (note the lack of spaces) to trace only the open, read, and write system calls. This can
minimize the amount of output you have to wade through if you've used -c to identify what you think are the
problem calls.
Finally, if you want more gory details for your traces, try -v, which gives full values of stat, environment, and
other common calls. (Use the -v flag and then have another look at the fstat call as discussed above to get all
the information that's returned about that file.)
Shell Script Wrappers
Although it's not always possible to run your command under "real" conditions when something goes wrong,
a possible workaround might be to write a shell script wrapper for the command so that you can run it via
strace.
Move your program command out of the way by renaming it to, for example, command.old. Then save the
script in Listing 4 to command.
Listing 4: Wrapping Another Command with strace
01 #!/bin/sh
02 #
03 strace -o/tmp/command_out.$$ /usr/bin/command.old $*
This not only calls the real command program with any arguments you used but also runs strace on it and
dumps the output to a new file each time the script is called. Then you can check out what's happening under
these real circumstances. Don't forget to move the real program back where it belongs once you're done!
Another very useful option is to use the -p PID option: This attaches strace to the process with the specified
process ID. So if you suddenly see a process hanging or eating up lots of CPU, you can find out what it's
doing in real time.
Dig Deep 4
Conclusion
Knowing what system calls should look like and how they work makes it much easier to notice when
something's not quite right. Often it's clear very quickly what's going wrong (e.g., a failed open call to a
particular file). Looking at file permissions can also be helpful.
Strace is incredibly useful when debugging, but it can also be educational to run it on programs or commands
that are running perfectly well, just to see what's going on under the hood of your working system.
One of the major advantages of running Linux is that the innards of the system are both accessible and
(largely) well documented. Strace is one of the tools that can let you make the most of this access.
INFO
[1] strace article part 1: http://www.linuxpromagazine.com/issues/2009/103/bug_bumper
[2] strace tool: http://sourceforge.net/projects/strace/
THE AUTHOR
Juliet Kemp has been playing around with Linux ever since she found out that it was more fun than Finals
revision, and has been a sys admin for about five years. She finds strace output deeply fascinating, and had
great fun delving into system call man pages while researching this article.
Dig Deep 5
[ Pobierz całość w formacie PDF ]