ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
#1 - write a small "hook" application to be the parent. All it does is fork() + exec() and waitpid()
#2 - ptrace() attach to the app, and let it continue executing. When it is delivered a signal, you can intercept. If it would exit() normally, your ptrace() call should fail with ESRCH.
#3 - watch a pid file, or /proc/ filesystem.
Last edited by orgcandman; 01-28-2011 at 09:35 AM.
#1 - write a small "hook" application to be the parent. All it does is fork() + exec() and waitpid()
This sounds a little difficult to implement, or at least to me. Because I don't understand why I need to execute the process any more with fork() + exec(). I repeat that the process is not handled for my applications and it's not a child neither.
Quote:
Originally Posted by orgcandman
#2 - ptrace() attach to the app, and let it continue executing. When it is delivered a signal, you can intercept. If it would exit() normally, your ptrace() call should fail with ESRCH.
Ok, I'm a newbie on Linux. I saw that ptrace like this:
trace any process in Linux, but, how i hope for the process and get the signal that tells me that the process is terminated? I have to use threads too?
Quote:
Originally Posted by orgcandman
#3 - watch a pid file, or /proc/ filesystem.
What I look for in /proc/filesystems? However, I do not think that this is a good solution.
#1 - write a small "hook" application to be the parent. All it does is fork() + exec() and waitpid()
#2 - ptrace() attach to the app, and let it continue executing. When it is delivered a signal, you can intercept. If it would exit() normally, your ptrace() call should fail with ESRCH.
The man page says:
Quote:
The ptrace() system call provides a means by which a parent process may observe and control the execution of another process,
Does it not mean that ptrace can work on the children of a particular process? If my understanding is wrong, correct me, if not, then OP has specified that he wants to observe unrelated processes too, how will the ptrace work in that case?
Hi.
You can use GDB as a higher-level interface to ptrace() syscall.
For example:
Create couple of files:
Code:
# file: eval-on-exit.gdb
catch syscall exit
catch syscall exit_group
commands 1 2 # catchpoints
shell './script.sh' # run any program you want
cont
end
cont
Code:
#!/bin/bash
# file: script.sh
# make it executable: chmod +x script.sh
echo 'End hook started'
Run the process in question if it is not yet. In this example I assume 'gvim' process is running.
When `gvim' exits (you type :q) `script.sh' will be executed. Here is a test run
Code:
$ gdb -batch -x eval-on-exit.gdb --quiet --pid=`pidof gvim`
[Thread debugging using libthread_db enabled]
0xb7835424 in __kernel_vsyscall ()
Catchpoint 1 (syscall 'exit' [1])
Catchpoint 2 (syscall 'exit_group' [252])
Catchpoint 2 (call to syscall 'exit_group'), 0xb7835424 in __kernel_vsyscall ()
End hook started
Program exited normally.
In my opinion this approach has a number of drawbacks (slow, do not work if SIGINT recieved etc) and simple polling of /proc should be used if you do not need to make some actions just before the process exit.
P.S. Following command allow gdb to attach to a running process without root priviledges (Ubuntu 10.10 and later):
Well, this is an approximation of a possible solution to my question and thanks to their answer I can expose there here. This is the code where I put two variants of notification: through the 'sigaction' and through the 'waitpid' within the cycle.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.