Non-interactive shell leaves children running when signaled by TERM


 
Thread Tools Search this Thread
Top Forums Shell Programming and Scripting Non-interactive shell leaves children running when signaled by TERM
# 1  
Old 09-09-2009
Non-interactive shell leaves children running when signaled by TERM

Hello.

When I run

Code:
sh -c 'yes'

and then send SIGTERM to sh's pid, both sh and yes dies.

When I run

Code:
sh -c 'yes | sed "s/y/n/"'

and then send SIGTERM to sh's pid, sh dies but yes and sed remain running in background with init as the parent.

Why?

I bash man page is stated that when bash is interactive and it receives SIGHUP, it sends SIGHUP to all its child processes.

Is it possible to achieve something similar when shell is non-interactive (ie. kill all child processes upon delivery of signal before exit)?

Thank you.

---------- Post updated at 10:05 PM ---------- Previous update was at 08:35 PM ----------

So I've got answer for the first question. It's because in first case shell just call exec, so the signal is delivered to yes. But in the second case, sh do 2 x fork and 2 x exec and waits for the child processes.
Login or Register to Ask a Question

Previous Thread | Next Thread

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

What is login and interactive shell?

Hi Guys, Excuse if am asking silly Que ... :rolleyes: Please explain me whats difference between login and interactive shell in Linux .. Have googled but still in doubt .. :confused: --Shirish Shukla (4 Replies)
Discussion started by: Shirishlnx
4 Replies

2. Shell Programming and Scripting

Interactive shell - Give answers to shell

Hi, I have a script that calles some other scripts. Those scripts are expecting some inputs. Right no I am typing manually. But now the number of questions from other scripts are too much and I want to give asnwers autimatically. example. Other scripts gives me 2 options 1) joom... (2 Replies)
Discussion started by: microsim
2 Replies

3. AIX

Finding name of script file that signaled my process

Is there a way to find out the path/name of a script file that signaled my process? All that shows up from the signal info data is ksh. Even in getprocs64 is is just ksh. I am not sure why the full path and file name are not showing up instead of the shell name. I tried ptrace64 with PT_LDINFO but... (4 Replies)
Discussion started by: soccertl
4 Replies

4. Shell Programming and Scripting

Interactive shell through a pipe

I'm new to working with pipes, so I don't know whether the following is expected behaviour or a bug on the part of an application. Since Version 0.47, Inkscape provides a non-GUI interactive shell mode of operation. I am trying to time the program's performance in converting SVG files to PNG... (1 Reply)
Discussion started by: ccprog
1 Replies

5. Homework & Coursework Questions

How to write script that behaves both in interactive and non interactive mode

Q. Write a script that behaves both in interactive and non interactive mode. When no arguments are supplied it picks up each C program from the directory and prints first 10 lines. It then prompts for deletion of the file. If user supplies arguments with the script , then it works on those files... (8 Replies)
Discussion started by: rits
8 Replies

6. Homework & Coursework Questions

Help with Interactive / Non Interactive Shell script

Q. Write a script that behaves both in interactive and non interactive mode. When no arguments are supplied it picks up each C program from the directory and prints first 10 lines. It then prompts for deletion of the file. If user supplies arguments with the script , then it works on those files... (1 Reply)
Discussion started by: rits
1 Replies

7. Shell Programming and Scripting

Search term and output term in desired field

Hi All, I have an input_file below and i would like to use Perl to search for the term "aaa" and output the 3rd term in the same row as "aaa".For Example, i want to search for the term "ddd" and would want the code to ouput the 3rd term in the same row which is "fff". Can somebody help ? ... (28 Replies)
Discussion started by: Raynon
28 Replies

8. Shell Programming and Scripting

Running an Interactive Program Remotely

now, i have a program that i would very much prefer to run remotely as i hate having to log into the box it is on. the problem is, every command i have tried to run this remotely doesn't work. the commands tries to kick off the program on the remote box but then hangs. like take for... (3 Replies)
Discussion started by: Terrible
3 Replies

9. Programming

Create a Term & Run chars on this Term

hi floks ! i'd like to know how can i transmete a character or a string from my source code to a term and make it interpret or un by the shell wich is running in my term. I'd like to create a Term from my code (and get its file descriptor) and then transmete each char typed on the keyboard to... (1 Reply)
Discussion started by: the_tical
1 Replies

10. News, Links, Events and Announcements

Flaw leaves Linux computers vulnerable

NEWS: Flaw leaves Linux computers vulnerable http://news.com.com/2100-1001-857265.html A flaw in a software-compression library used in all versions of Linux could leave the lion's share of systems based on the open-source operating system open to attack, said sources in the security... (3 Replies)
Discussion started by: killerserv
3 Replies
Login or Register to Ask a Question
KILLPROC(8)						       The SuSE boot concept						       KILLPROC(8)

NAME
Killproc - Send signals to processes by full path name SYNOPSIS
killproc [-vqLN] [-g|-G] [-p pid_file] [-i ingnore_file] [-c root] [-t <sec>] [-<SIG>] /full/path/to/executable killproc -n [-vq] [-g|-G] [-t <sec>] [-<SIG>] name_of_kernel_thread killproc [-vq] [-g|-G] [-t <sec>] [-<SIG>] basename_of_executable killproc -l SYNOPSIS LSB 3.1 killproc [-p pid_file] /full/path/to/executable [-<SIG>] DESCRIPTION
killproc sends signals to all processes that use the specified executable. If no signal name is specified, the signal SIGTERM is sent. If this program is not called with the name killproc then SIGHUP is used. Note that if no signal is specified and the program killproc does not terminate a process with the default SIGTERM the signal SIGKILL is send after a few seconds (default is 5 seconds, see option -t). If a program has been terminated successfully and a verified pid file was found, this pid file will be removed if the terminated process didn't already do so. killproc does not use the pid to send a signal to a process but the full path of the corresponding program which is used to identify the executable (see proc(5)). Only if inode number (/proc/<pid>/exe) and full path name of the executable (/proc/<pid>/cmdline) are unavail- able or if the executable has changed its zeroth argument, killproc uses the base name (/proc/<pid>/stat) to identify the running program. Note that if the option -n for kernel thread is given, only (/proc/<pid>/stat) is used. For this case an existing symbolic link (/proc/<pid>/exe) indicates that the <pid> is not a kernel thread. The last variant of the killproc call is only with the basename of the executable. This is required by the Linux Standard Base Specifica- tion (LSB). Note that this disables the comparision of the inodes of the executable and the information found within the proc table (see proc(5)). This implies that if no pid file is found it may happens that programs or script with the same base name will killed instead. killproc tries to determine the pid of its parent and pid of the parent of its parent to not to kill those two processes. Extended functionality is provided by the -p pid_file option (former option -f changed due to the LSB specification). If this option is specified, killproc tries to send the signal to the pid read from this file instead of from the default pid file (/var/run/<basename>.pid). If the pid_file does not exist, killproc assumes that the daemon is not running. It is possible to use a process identity number instead of a pid file. For the possibility of having two different sessions of one binary program, the option -i ignore_file allows to specify a pid file which pid number is used to ignore all processes of corresponding process session. The option -v turns on verbosity about which signal is being sent. The option -q is ignored for compatibility with older versions. If the option -G is used, the signal will not only sent to the running executable, but also to all members of the session that the specified exe- cutable leads. Whereas the option -g the signal sends to the group including the executable. If unsure use -G. REQUIRED
/full/path/to/executable or name_of_kernel_thread Specifies the executable to which the signal should be sent, or alternatively, if the option -n is used, the name of the kernel thread. This argument is always required. OPTIONS
-G Sends the signal to all session followers (children) of the identified process. -g Sends the signal to all members of the session including the identified process. Note that usually the option -G should be used. -L This option causes symlinks to be followed, as the like-named option in ls(1). Note: for the file name the original name of the program is used instead of the name of the symbolic link. -p pid_file (Former option -f changed due to the LSB specification.) Use an alternate pid file instead of the default (/var/run/<base- name>.pid). If the pid_file does not exist, killproc assumes that the daemon is not running. It is possible to use a process iden- tity number instead of a pid file. -i ignore_file The pid found in this file is used as session id of the same binary program which should be ignored by killproc. -c root Change root directory to root for services which have been started with this option by startproc(8). -n This option indicates that a kernel thread should be signaled. In this case not the executable with its full path name is required but the name of the kernel thread. -N With this option the location of the executable is checked about NFS file system and if true the stat(2) system call is not applied on the exe symbolic link under /proc(5). Otherwise killproc could be locked if the corresponding NFS server is currently not online or available. This implies that the inode number check between the exectuable on the command line and the exectuable of the exec symbolic link will be skipped. -<SIG> Signals can be specified either by name (e.g. -HUP, -SIGHUP) or by number (e.g. -1). -t<sec> The number <sec> specifies the seconds to wait between the sent signal SIGTERM and the subsequentially signal SIGKILL if the first SIGTERM does not show any result within the first few milli seconds. This defaults to 5 seconds. -q This option is ignored. -v Be more verbose. -l This option list all available signals and some of their synonyms by their number and signal names to standard out. and exits. EXAMPLES
killproc -TERM /usr/sbin/sendmail sends the signal SIGTERM to the running sendmail process. If a pid file sendmail.pid exists in /var/run/ then the pid from this file is being used after verification to terminate the sendmail process. Other running processes are ignored. killproc -p /var/myrun/lpd.pid -TERM /usr/sbin/lpd sends the signal SIGTERM to the pid found in /var/myrun/lpd.pid if and only if this pid belongs to /usr/sbin/lpd. If the named /var/myrun/lpd.pid does not exist, killproc assumes that the daemon of /usr/sbin/lpd is not running. The exit status is set to 0 for successfully delivering the given signals SIGTERM and SIGKILL otherwise to 7 if the program was not running. It is also suc- cessful if no signal was specified and no program was there for Termination because it is already terminated. EXIT CODES
The exit codes have the following LSB conform conditions: 0 Success or program was not running (no signal specified) 1 Generic or unspecified error 2 Invalid or excess argument(s) 4 Insufficient privilege(s) 5 Program is not installed 7 Program was not running to receive the specified signal In some error cases, diagnostic output is sent to standard error, or, if standard error is not available, syslogd(8) is being used. NOTE
killproc is a replacment for the Bourne shell function killproc found in the widely used SysVinit package of Miquel van Smoorenburg, <miquels@cistron.nl>. BUGS
Identifying a process based on the executable file and the corresponding inode number only works if the process stays alive during kill- proc's execution. Impure executables like shell scripts (the inode number of the shell is not identical to that of the script) and programs rewriting their zeroth argument may not be identified by a file name. Killproc isn't able to signal processes being in the zombie state. Zombies are processes which arn't alive but listed in the process table to have the exit status ready for the corresponding parent processes. FILES
/proc/ path to the proc file system (see proc(5)). /etc/init.d/ path to the SuSE boot concept script base directory as required by the Linux Standard Base Specification (LSB) (see init.d(7)). SEE ALSO
startproc(8), checkproc(8), insserv(8), init.d(7), kill(1), skill(1), killall(8), killall5(8), signal(7), proc(5). COPYRIGHT
1994-2005 Werner Fink, 1996-2005 SuSE GmbH Nuernberg, Germany. AUTHOR
Werner Fink <werner@suse.de> 3rd Berkeley Distribution Nov 10, 2000 KILLPROC(8)