UNIX for Advanced & Expert Users

Reference post #7.
Please post what Operating System and version you are running and what Shell is /bin/sh. Also please provide an overview of the hardware because we are still concerned that you are bombarding the kernel with ps -ef commands when you are only interested in a few processes. A unix kernel can and will ignore or not complete ps -ef commands when it has better things to do.

I can't see why you run shell scripts with sh myscriptname.ksh rather than making the script executable and running the script with an absolute pathname.

As @alister points out. If you are spawning a short-duration shell script a ps snapshot may not see it at all. Besides which @alister has explained sub-shells very well.

I seriously hope you're doing all this digging for the sake of curiosity and education rather than trying this hard to get your process management script to work. The easy and correct method to solve this is using a PID file, as said posts ago.

There is still a difference. Originally you use backticks and a here-doc. Your test does not use a here-doc. I cannot explain how or when, but ksh does eliminate the need for some subshells. The last command in a pipeline comes in mind. Here is that example:

Code:

$ sh -c 'echo hello world | read var; echo "$var"'

$ ksh -c 'echo hello world | read var; echo "$var"'
hello world

Again ksh saves a subshell here:

Code:

$ sh -c 'var=`ps auxwf |grep [s]h`; echo "$var"'
mute     22212  0.0  0.4   4140  1160 pts/3    S+   01:47   0:00      \_ sh -c var=`ps auxwf |grep [s]h`; echo "$var"
mute     22213  0.0  0.2   4140   580 pts/3    S+   01:47   0:00          \_ sh -c var=`ps auxwf |grep [s]h`; echo "$var"
$ ksh -c 'var=`ps auxwf |grep k[s]h`; echo "$var"'
mute     22217  0.0  0.5   4576  1464 pts/3    S+   01:47   0:00      \_ ksh -c var=`ps auxwf |grep k[s]h`; echo "$var"

Trying with or without a here-doc is left as an exercise to the reader.

Oh but wait!! Your script ends with ksh, but you don't even use ksh to execute it...

NutronScott you are absolutely right. This is more of a self education because now I know that I have to ask my team to invoke this script via nohup scriptname.ksh or ksh scriptname.ksh instead of sh scriptname.ksh. As you mentioned it was a wrong idea to invoke a ksh script with sh. But since this script is related to a corporate application that includes several informatica workflows, these trigger scripts are run by different teams across the world within the firm based on failures / maintenance releases that happen. As a result it is difficult control how different members of the team trigger these scripts. Anyway by digging deep into this issue in this forum, and based on what you have said, sh does invoke additional subshell compared to ksh and my tests with strace that alister suggested also revealed the same. BTW the reason I used HEREDOC in the first example is because I was using sqlplus and so it needs a delimiter to know when the oracle DML operation is ending. Whereas in the 2nd example there was no ORacle command involved and so I didnot need a HEREDOC. The version of Linux I am using is SuSE 10.3

For your info, here is an output from the strace command strace -e trace=process -f sh /tmp/testdbqueryforstrace.ksh
where testdbqueryforstrace.ksh is my sample script listed earlier that contains just an sqlplus command in backticks
As you can see first an execve is called to run sh /tmp/testdbquerforstrace.ksh. This happens even in ksh. So it is a common step
Then distinction with sh is in the next step where this process clones a child process (pid 9806) which is again sh /tmp/testdbqueryforstrace.ksh
This child process then again clones another child process (pid 9808) which is the sqlplus -s upon which parent process 9806 is suspended
When sqlplus command exits, 9808 is detached and 9806 resumes. When /tmp/testdbqueryforstrace.ksh exits 9806 is detached and its parent process sh /tmp/testdbqueryforstrace.ksh which is invoked through execve resumes.

Code:

execve("/bin/sh", ["sh", "/tmp/testdbqueryforstrace.ksh"], [/* 57 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x2ad59aa0bae0) = 0
clone(Process 9806 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2ad59aa0bb70) = 9806
[pid  9806] clone(Process 9808 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2ad59aa0bb70) = 9808
[pid  9806] wait4(-1, Process 9806 suspended
 <unfinished ...>
[pid  9808] execve("/app/oracle//bin/sqlplus", ["sqlplus", "-s", "ETL_RW/ETL_RW2011@PNY00600"], [/* 106 vars */]) = 0
[pid  9808] arch_prctl(ARCH_SET_FS, 0x2b803321bae0) = 0
[pid  9808] exit_group(0)               = ?
Process 9806 resumed
Process 9808 detached
[pid  9806] <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 9808
[pid  9806] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid  9806] wait4(-1, 0x7fffd99cb7c4, WNOHANG, NULL) = -1 ECHILD (No child processes)
[pid  9806] exit_group(0)               = ?
Process 9806 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 9806
wait4(-1, 0x7fffd99cb994, WNOHANG, NULL) = -1 ECHILD (No child processes)
exit_group(0)                           = ?

Then I ran the same strace command using ksh. Here is the ouput for strace command strace -e trace=process -f ksh /tmp/testdbqueryforstrace.ksh
As you can see the first step is the same as in using sh where the execve is invoked to spawn a new program ksh /tmp/testdbqueryforstrace.ksh
Distinction in the 2nd step when vfork is used instead of clone. And in addition to that difference, the vfork is used to spawn a child process (pid 5180) which is actually sqlplus -s command and not another ksh /tmp/testdbqueryforstrace.ksh. Its parent is directly the one created through execve (pid 5163). 5163 is suspended when sqlplus runs. When sqlplus ends, 5180 is detached and 5163 resumes.
When 5163 exits there is no more parent process waiting on it unlike in sh, because 5163 itself is the parent. So there is one level of less cloning here

Code:

execve("/usr/bin/ksh", ["ksh", "/tmp/testdbqueryforstrace.ksh"], [/* 57 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x2abb87300ae0) = 0
vfork(Process 5180 attached (waiting for parent)
Process 5180 resumed (parent 5163 ready)
)                                 = 5180
[pid  5163] wait4(-1, Process 5163 suspended
 <unfinished ...>
[pid  5180] execve("/app/oracle//bin/sqlplus", ["sqlplus", "-s", "ETL_RW/ETL_RW2011@PNY00600"], [/* 108 vars */]) = 0
[pid  5180] arch_prctl(ARCH_SET_FS, 0x2ae86ab5fae0) = 0
[pid  5180] exit_group(0)               = ?
Process 5163 resumed
Process 5180 detached
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) = 5180
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7ffff8eae56c, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD (No child processes)
wait4(-1, 0x7ffff8eae56c, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD (No child processes)
exit_group(0)                           = ?

While the above test does show how an additional cloning happens in Linux when using sqlplus and invoking through sh, the gray area that still is when running strace on a 2nd example where the script calls another sleepscript in backticks instead of sqlplus, strace output showed even when invoking with sh, clone was called only once not twice. I guess I have to just live with that inconsistency in behaviour for now.

It may be avoiding a clone or fork by using a shell builtin. This is not an "inconsistency" -- it is a performance gain.

What exactly must you 'live with'? In what way is the code not actually functioning?