ltrace doesn't work on some binaries

Question

According to the man page, ltrace is supposed to intercept and record the dynamic library calls on any executed process, however it seems to not work properly on some binaries.

Here is the way to reproduce the problem while trying to trace strcpy.

I first see that ltrace is able to work on some binary (wget here):

# ltrace -e strcpy wget --help >/dev/null
strcpy(0x63cc23, "auth-no-challenge")            = 0x63cc23
strcpy(0x63cc38, "background")                   = 0x63cc38
[...]
strcpy(0x63cf26, "verbose")                      = 0x63cf26
strcpy(0x63cf31, "verbose")                      = 0x63cf31
+++ exited (status 0) +++

Now the same code doesn't work on httpd:

# ltrace -e strcpy /usr/sbin/httpd -t >/dev/null
Syntax OK
+++ exited (status 0) +++

No library call was traced, although we can confirm that strcpy is called using gdb:

# gdb --quiet --args /usr/sbin/httpd -t 
Reading symbols from /usr/sbin/httpd...(no debugging symbols found)...done.
(gdb) b strcpy
Breakpoint 1 at 0x15d08
(gdb) r
Starting program: /usr/sbin/httpd -t
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaad1b000
[Thread debugging using libthread_db enabled]

Breakpoint 1, 0x00002aaaaca4d610 in strcpy () from /lib64/libc.so.6

I'm performing this on Fedora 17. Is this a ltrace bug or expected behaviour?

Answer 1

To achieve the expected permissions (setuid and friends) and a proper daemon configuration, httpd is forking itself soon after it starts, and the original process then exits (before strcpy() is ever called, it seems). gdb automatically follows the new process, and ltrace can follow it, but you have to tell it to by giving it some additional options, e.g. ltrace -f.