* Info wrote on Wed, Oct 24, 2001 at 15:07 +0200:

there are the 2 binaries

ptrace strace

let me add ltrace which traces lib calls. Please note the -p and -f options which are really helpful. With -p, you can trace an already running (hanging?) programm. If you want to really know, there are a lot of possibilities. I like gdb :) You can use gdb /path/to/bin PID to attach a running programm. You can do anythink you want here :) Well, usually it's easy to rebuild a source RPM. At least with a few changes in the SPEC (add --enable-debug to the configure call or similar) and a rpm -ba package.SPEC (after installing the source RPM of course :)) you have a debug build. The you can gdb it with haveing the sources at the hand, all variable names and whatever. But for the particular file descriptor question the alread mentioned lsof should be the right :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Bill Bishop wrote:

For this purpose, lsof is ideal, because it is lighter-weight than ptrace or strace.

B^2 ;) Bill Bishop b@bandkshow.com

...

-----Original Message----- From: Peter Schanbacher [mailto:peter.schanbacher@procreo.de] Sent: Wednesday, October 24, 2001 5:52 AM To: suse-security@suse.com Subject: [suse-security] control a program

hi list,

is there any possibility to watch what exactly a program/process is doing? I want to know what files are written by one process.

MfG Peter

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

I use pstree with the -p option quite often. Then I get a hierarchical tree of parent processes and their child processes, with the init process (that's the first process on Linux) as the root node. The -p option adds the process id or pid as it is called. Knowing which process is the parent and knowing that parent's pid, you can issue a kill -9 pid (i.e. kill -9 4567) to stop that process and it's child processes. Sometimes the children don't behave, so run pstree afterwards to check if you got them all. If I need to know which open files belong to which process, I run lsof or LiSt Open Files. With no extra options you get all open files, so run pstree -p to find the pid of the process you're interested in, then run lsof with the -p option, i.e. lsof -p 4567, to get only those files held by that process. Sometimes lsof is not enough, at least not the way I use it (any hints are welcome). For instance, you start a process and it fails on you - crash. What on earth is lsof going to tell you in that situation? The processs is dead for no apparent reason, so there are no open files belonging to it. It doesn't have to crash either, because if the process opens a file and then closes it, lsof only shows you open files at the moment, so any config-files that have been read and closed will not show up. Enter strace. If you are running X and an X program fails on you, like a bunch of KDE-apps did after I upgraded to 2.1, open a consol window, and type for example: strace kwrite This will start kwrite with a trace of system calls.Lots of text will fly by, and you can use the scroll bar to go up and see what is going on. In my case there where several open(/path/to/some file) with the helpful text No such file or directory at the end of the line. Doing a whereis lostfile gave me the path to missing file Doing a check against the RedHat Package Manager database to find the package owning the file rpm -qf /path/to/lostfile gave me the package name. Next doing a rpm -qpl package.rpm showed where the package would put the files. Personally I would like a tool that did all of this in one go. The KDE-process control program could have three extra tabs. When you first opened it showed all processes, when you highlighted a process the lsof-tab became available, and when clicked would show all open files belonging to that process. Hitting the strace-tab, would start strace on that process (not quite sure how to start a process with strace in this extended process control program), and finally an rpm-tab, showing which package owned the open files and the missing files if that's the problem. Haakon Meland Eriksen haakon@nhn.no