Wednesday, May 08, 2013


truss traces library and system calls and signal activity for a given process. This can be very useful in seein where a program is choking.

In order to be able to use truss output, it is important to understand some basic vocabulary:

  • brk() requests memory during execution.
  • exec() opens a program.
  • fcntl() performs control functions on open files.
  • fstat() obtains information about open files.
  • getdents64() reads directory information.
  • ioctl() performs terminal I/O.
  • lstat() obtains file attributes.
  • mmap() maps the program image into memory.
  • open() opens a file. It returns a number which is referenced when the file is used.
  • write() writes to an open file/device.

Obviously, this is only a subset of the system calls seen in truss output, but this subset is usually sufficient to figure out what is going on. Other system calls can be looked up in the vendor web pages or man pages.

In most cases we will be looking for error messages in the truss output. These entries will contain the string "Err" in the last column of the output.

These errors can be categorized as system call errors or missing file errors. Many missing file errors are the result of a library not being in a directory early in the LD_LIBRARY_PATH or something of the sort. If the truss output shows a successful open() (or whatever) of the file name later in the process, that is probably not your culprit.

System call errors can be interpreted by looking at the man page of the specific system call or examining the file /usr/include/sys/errno.h.

Sometimes you need more information than truss offers. Dtrace offers a finer-grained method for examining every aspect of a process's functioning.

No comments: