[src] cvs commit: src/include unistd.h src/lib/libc/sys
readlink.2 src/sys/compat/freebsd32 syscalls.master
src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys
syscallsubr.h
Dag-Erling Smørgrav
des at des.no
Mon Feb 18 10:45:16 UTC 2008
"Daniel O'Connor" <doconnor at gsoft.com.au> writes:
> Giorgos Keramidas <keramida at freebsd.org> writes:
> > Specifying stdout may be a bit tricky, since the traced application
> > may be using the same stream to print output. The same is possible
> > with stderr, but may be a tiny bit less likely.
> I didn't realise that the file descriptor used to write tracing data
> out was 'owned' by the process being traced, I always thought ktrace
> did.
ktrace does absolutely nothing other than enable tracing and exec the
application. The 'k' in "ktrace" means "kernel".
> I did have a look at the source and the file opening etc is handled by
> the kernel but I am not sure who 'owns' that file descriptor.
There is no file descriptor. There is a vnode in the kernel which is
not listed in the traced process's file table. This is the whole point
of ktrace: it is undetectable by the traced process.
> I guess it couldn't be moved to ktrace without rearchitecting how
> ktracing works so the ktrace process sticks around writing stuff out
> to disk.
...which would make it just as useless as truss, since it would (among
other things) change the way job control works for the traced process.
DES
--
Dag-Erling Smørgrav - des at des.no
More information about the freebsd-current
mailing list