Re: [gentoo-user] [OT] kill a child and suicide
On Wed, 3 May 2006, Zac Slade wrote: On Wednesday 03 May 2006 16:04, Jorge Almeida wrote: But I won't be able to use svc to interact with the child. That's why I feel I must reformulate the whole setup. If you need deeper interaction with a child process then you might need to look outside the realm of shell. I'd suggest looking at perl. Not that you can't accomplish what you are looking for with bash scripting, but you may be better served by using a more full featured programming language than shell offers. Perhaps. I know more of Perl than of Bash, but a shell script is the usual way to run a process supervised by daemontools. The problem with backgrounding the child is that it may die for some reason and supervise won't be able to ressurrect it. I'll take a look at CPAN... Thanks. -- Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Tue, 2 May 2006, Jorge Almeida wrote: parent.sh #!/bin/bash do something /path/to/child.sh do something else It's just bash scripting, just tell bash to exec child.sh in the background. /path/to/child.sh Christopher Fisk -- Stewie Griffin: Mother, life is like a box of chocolates. You never know what you're going to get. Your life, on the other hand, is like this box of ACTIVE GRENADES! Lois Griffin: [oblivious] Oh, you want your toy back. Here you go. [Gives Stewie his Ray-Gun toy] Stewie Griffen: Yes... well... VICTORY IS MINE! [he runs off - the sound of the grenades exploding is heard] Stewie Griffen: BLAST! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Wed, 3 May 2006, Christopher Fisk wrote: It's just bash scripting, just tell bash to exec child.sh in the background. /path/to/child.sh Nope. I need the child in the foreground, so that its output and stderr goes to multilog. Thanks, Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Wednesday 03 May 2006 11:25, Jorge Almeida [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] [OT] kill a child and suicide': On Wed, 3 May 2006, Christopher Fisk wrote: It's just bash scripting, just tell bash to exec child.sh in the background. /path/to/child.sh Nope. I need the child in the foreground, so that its output and stderr goes to multilog. Putting something in the background doesn't change what it's std(in|out| err) are attached to. They will still go to the [pt]ty like normal. If you *want* then redirected somewhere else, you are free to do so with standard redirection operations before the ampersand. -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh pgpE4pmfoJ0yL.pgp Description: PGP signature
Re: [gentoo-user] [OT] kill a child and suicide
On Wed, 3 May 2006, Boyd Stephen Smith Jr. wrote: Putting something in the background doesn't change what it's std(in|out| err) are attached to. They will still go to the [pt]ty like normal. If Right, my mistake. Still, the parent script will exit sucessfuly, and then how can the backgrounded process be controlled, other than by killing it with kill -TERM or something like that? you *want* then redirected somewhere else, you are free to do so with standard redirection operations before the ampersand. I don't want redirection. Multilog will grasp stdout, but only of the parent process (I think); once the latter exits, I don't think the other process will be accessible. Thanks, Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
Hi, On Wed, 3 May 2006 20:38:49 +0100 (WEST) Jorge Almeida [EMAIL PROTECTED] wrote: On Wed, 3 May 2006, Boyd Stephen Smith Jr. wrote: Putting something in the background doesn't change what it's std(in|out| err) are attached to. They will still go to the [pt]ty like normal. If Right, my mistake. Still, the parent script will exit sucessfuly, and then how can the backgrounded process be controlled, other than by killing it with kill -TERM or something like that? Signals are the only way (or you have a parent died logic inside the child process). And this will always open a racing condition when relying on shell scripting, like I showed in my earlier answer. But for multilog this won't matter as stdin/stdout is dup'ed to the child. It does matter, though, for security holes. you *want* then redirected somewhere else, you are free to do so with standard redirection operations before the ampersand. I don't want redirection. Multilog will grasp stdout, but only of the parent process (I think); once the latter exits, I don't think the other process will be accessible. It doesn't exit. It's just a shell built-in wait (no, in fact, it is a glibc built-in wait). The file handles are kind of dup'ed, so multilog should work just fine. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Wed, 3 May 2006, Hans-Werner Hilse wrote: Signals are the only way (or you have a parent died logic inside the child process). And this will always open a racing condition when But I won't be able to use svc to interact with the child. That's why I feel I must reformulate the whole setup. you *want* then redirected somewhere else, you are free to do so with standard redirection operations before the ampersand. I don't want redirection. Multilog will grasp stdout, but only of the parent process (I think); once the latter exits, I don't think the other process will be accessible. It doesn't exit. It's just a shell built-in wait (no, in fact, it is a glibc built-in wait). The file handles are kind of dup'ed, so multilog should work just fine. Thanks again. Writing to this list is never a waste of time! -- Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Wednesday 03 May 2006 16:04, Jorge Almeida wrote: On Wed, 3 May 2006, Hans-Werner Hilse wrote: Signals are the only way (or you have a parent died logic inside the child process). And this will always open a racing condition when But I won't be able to use svc to interact with the child. That's why I feel I must reformulate the whole setup. If you need deeper interaction with a child process then you might need to look outside the realm of shell. I'd suggest looking at perl. Not that you can't accomplish what you are looking for with bash scripting, but you may be better served by using a more full featured programming language than shell offers. -- Zac Slade [EMAIL PROTECTED] ICQ:1415282 YM:krakrjak AIM:ttyp99 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Tuesday 02 May 2006 14:40, Jorge Almeida wrote: parent.sh #!/bin/bash do something /path/to/child.sh do something else When parent.sh receives a TERM signal, I would like child.sh to receive TERM also, and then parent.sh receive TERM. The do something else part is why I can't use exec /path/to/child.sh. Is there some way to achieve this? I think (untested) you can do something like trap 'kill pid of child' TERM at then beginning of parent.sh. This way, when the parent recives TERM it in turn sends a TERM to the child. If you want the parent to terminate, add the exit command as well: trap 'kill pid of child; exit 1' TERM (don't know how the parent can wait for termination of child, but it should be possible I think) man trap gives you the details. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Tue, 2 May 2006, Etaoin Shrdlu wrote: I think (untested) you can do something like trap 'kill pid of child' TERM at then beginning of parent.sh. This way, when the parent recives TERM it in turn sends a TERM to the child. If you want the parent to terminate, add the exit command as well: trap 'kill pid of child; exit 1' TERM But how to find out the PID of child? What would be convenient is a way to send signals recursively to a process and its children. Maybe I'm trying to solve a problem with wrong tools... Thanks, Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
pkill has a -g option to send a signal to a process group. --- Vladimir On Tue, 2006-05-02 at 14:48 +0100, Jorge Almeida wrote: On Tue, 2 May 2006, Etaoin Shrdlu wrote: I think (untested) you can do something like trap 'kill pid of child' TERM at then beginning of parent.sh. This way, when the parent recives TERM it in turn sends a TERM to the child. If you want the parent to terminate, add the exit command as well: trap 'kill pid of child; exit 1' TERM But how to find out the PID of child? What would be convenient is a way to send signals recursively to a process and its children. Maybe I'm trying to solve a problem with wrong tools... Thanks, Jorge Almeida Vladimir G. Ivanovic Palo Alto, CA 94306 +1 650 678 8014 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Tuesday 02 May 2006 08:48, Jorge Almeida wrote: On Tue, 2 May 2006, Etaoin Shrdlu wrote: I think (untested) you can do something like trap 'kill pid of child' TERM at then beginning of parent.sh. This way, when the parent recives TERM it in turn sends a TERM to the child. If you want the parent to terminate, add the exit command as well: trap 'kill pid of child; exit 1' TERM But how to find out the PID of child? What would be convenient is a way to send signals recursively to a process and its children. Maybe I'm trying to solve a problem with wrong tools... Thanks, You can find the PID of the last backgrouned process using the bash variable $! So something like: subprocess $pid=$! Using trap along with maybe setting alarms should get you what you want. -- Zac Slade [EMAIL PROTECTED] ICQ:1415282 YM:krakrjak AIM:ttyp99 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Tue, 2 May 2006, Zac Slade wrote: You can find the PID of the last backgrouned process using the bash variable $! The child is not backgrounded! So something like: subprocess $pid=$! Using trap along with maybe setting alarms should get you what you want. Based on the suggestions of Uwe and Vladimir, I tried trap 'pkill -TERM -P $$; kill -s TERM $$' TERM do something . /path/to/child.sh do something else Doesn't work, yet. Note that child.sh is a shell script that may execute some other command (like rsync), so the . by itself may not be enough. Thanks everyone. Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
Hi, On Tue, 2 May 2006 17:42:26 +0100 (WEST) Jorge Almeida [EMAIL PROTECTED] wrote: On Tue, 2 May 2006, Zac Slade wrote: You can find the PID of the last backgrouned process using the bash variable $! The child is not backgrounded! So something like: subprocess $pid=$! Using trap along with maybe setting alarms should get you what you want. Based on the suggestions of Uwe and Vladimir, I tried trap 'pkill -TERM -P $$; kill -s TERM $$' TERM do something . /path/to/child.sh do something else Doesn't work, yet. Note that child.sh is a shell script that may execute some other command (like rsync), so the . by itself may not be enough. This can't work because of this (man bash): --snip If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. --snip What instead works (just tested): --snip #!/bin/sh COMMAND=sleep 120 # First we background: $COMMAND # Save the PID CHILDPID=$! # Trap the signal: trap kill -TERM $CHILDPID TERM # And wait for the Child to finish: wait $CHILDPID # reset signal handling: trap - TERM --snip Note that the code could hit a racing condition and should therefore not carelessly run by root on a machine with untrusted users. This is: The process may have finished before setting the signal handler. Other processes *might* reuse the PID afterwards and might get sig-TERM-ed until resetting the signal handler again. Probably a minor, depending on the script's usage. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] kill a child and suicide
On Tue, 2 May 2006, Hans-Werner Hilse wrote: Based on the suggestions of Uwe and Vladimir, I tried trap 'pkill -TERM -P $$; kill -s TERM $$' TERM do something . /path/to/child.sh do something else Doesn't work, yet. Note that child.sh is a shell script that may execute some other command (like rsync), so the . by itself may not be enough. This can't work because of this (man bash): --snip If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. --snip Oops...! What instead works (just tested): --snip #!/bin/sh COMMAND=sleep 120 # First we background: $COMMAND # Save the PID CHILDPID=$! # Trap the signal: trap kill -TERM $CHILDPID TERM # And wait for the Child to finish: wait $CHILDPID # reset signal handling: trap - TERM --snip Backgrounding is really not an option. The whole setup is to be supervised by daemontools. Note that the code could hit a racing condition and should therefore not carelessly run by root on a machine with untrusted users. This is: The process may have finished before setting the signal handler. Other processes *might* reuse the PID afterwards and might get sig-TERM-ed until resetting the signal handler again. Probably a minor, depending on the script's usage. Precisely the kind of thing I want to avoid. I think I need to reformulate my setup. Thanks. Jorge Almeida -- gentoo-user@gentoo.org mailing list
