[SunHELP] for loop changes nohup?
DAUBIGNE Sebastien - BOR
sebastien.daubigne at atosorigin.com
Thu Nov 25 02:22:12 CST 2004
Ok, so both java process have reset the SIGHUP handler to default (caught
+RESTART), so they're not imune to SIGHUP.
Now for the "for loop" behaviour, I made a test, replacing java by a sleep
command, and removing nohup (because sleep will not reset SIGHUP handler)
(traces below).
In this test :
- "sleep 503" is launched directly via the couple of scripts
- "sleep 501" is launched with the for loop via the couple of scripts
- "sleep 502" is launched directly from shell without script ("sleep 502 &")
Now for the explanation of the behaviour :
- 503 is member of a orphaned process group (interactive shell creates a
separate process group, then the process group leader forks and die, leaving
every orphan son in an orphan process group) : the remaining process becomes
orphan (father=1) but keeps the process group number of its died father. As
member of a orphaned process group, it will not receive SIGHUP when the
terminal will hangup (see truss output).
- 501 is member of a the foreground process group (interactive shell doesn't
create a separate process group because of the "for loop", so every
remaining shell keeps the process group of the first shell) : this is the
process group of the interactive shell. As member of a foreground process
group, it will receive SIGHUP when the terminal will hangup, then it will
die, because of the default SIGHUP handler (see truss output).
- 502 is member of a background process group (interactive shell creates a
separate background process group for the background sleep command) : the
remaining process is a background process group leader. As member of a
background process group, it will receive SIGHUP when the terminal will
hangup, then it will die, because of the default SIGHUP handler (see truss
output).
This is why one of your java process will die (foreground process
group=SIGHUP), and the other won't (orphaned process group=NO SIGHUP).
Of course, if the java virtual machine had not reset the SIGHUP handler,
both would have remained imune to SIGHUP and would not have died.
Now, the question remains : why does interactive KSH not create a separate
process group for each command in a loop ?
Interactive Ksh should do it, unless job control facility is disabled with
"set +o monitor", which is the default for non-interactive Ksh.
One more thing : I've also tested HPUX 11.0's KSH and guess what ? It has
the same bug (or feature). Probably a footprint from Unix tools old days (I
suppose every commercial Unix standard tools sources are veeeeery close from
Bell Labs one, even in 2004).
My test :
/daubigne # ps -fju daubigne
UID PID PPID PGID SID C STIME TTY TIME CMD
daubigne 13635 13582 13635 13635 0 18:47:12 pts/7 0:00 -ksh
daubigne 15155 15144 15155 15155 0 18:32:46 pts/10 0:01 -ksh
daubigne 17225 1 13635 13635 0 18:48:52 pts/7 0:00 sleep 501
daubigne 16553 1 16551 13635 0 18:48:42 pts/7 0:00 sleep 503
daubigne 17461 13635 17461 13635 0 18:49:08 pts/7 0:00 sleep 502
/daubigne # truss -aeflv all -p 17225 16553 17461
17225/1: psargs: sleep 501
17461/1: psargs: sleep 502
16553/1: psargs: sleep 503
17225/1: sigsuspend(0xFFBEFAE8) (sleeping...)
17225/1: sigmask = 0 0 0 0
16553/1: sigsuspend(0xFFBEFAE8) (sleeping...)
16553/1: sigmask = 0 0 0 0
17461/1: sigsuspend(0xFFBEFAE8) (sleeping...)
17461/1: sigmask = 0 0 0 0
17461/1: Received signal #1, SIGHUP, in sigsuspend() [default]
17461/1: siginfo: SIGHUP pid=13635 uid=133
17461/1: sigsuspend(0xFFBEFAE8) Err#4 EINTR
17461/1: sigmask = 0 0 0 0
17461/1: *** process killed ***
17225/1: Received signal #1, SIGHUP, in sigsuspend() [default]
17225/1: sigsuspend(0xFFBEFAE8) Err#4 EINTR
17225/1: sigmask = 0 0 0 0
17225/1: *** process killed ***
/daubigne # ps -fju daubigne
UID PID PPID PGID SID C STIME TTY TIME CMD
daubigne 15155 15144 15155 15155 0 18:32:46 pts/10 0:01 -ksh
daubigne 16553 1 16551 13635 0 18:48:42 ? 0:00 sleep 503
--
Sebastien DAUBIGNE
Sebastien.daubigne at atosorigin.com <mailto:Sebastien.daubigne at atosorigin.com>
- +33(0)5.57.26.56.36
AtosOrigin Infogerance - IMS/ERP/Pessac
-----Message d'origine-----
De : sunhelp-bounces at sunhelp.org [mailto:sunhelp-bounces at sunhelp.org]De
la part de Richard Russell
Envoyi : mardi 23 novembre 2004 12:05
@ : The SunHELP List
Cc : The SunHELP List; sunhelp-bounces at sunhelp.org
Objet : RE: [SunHELP] for loop changes nohup?
Thanks... I suppose I could chase up ksh or Solaris people about whether
this is a bug or feature...
psig trace from direct start:
----
$USER@$HOST:$HOME > ./start
+ nohup $HOME/start2
Sending output to nohup.out
$USER@$HOST:$HOME > ps -ju $USER
PID PGID SID TTY TIME CMD
10589 10589 10589 pts/12 0:00 ksh
11054 11052 10589 pts/12 0:01 java
$USER@$HOST:$HOME > psig 11054
11054: $JAVA_HOME/bin/../bin/sparc/native_threads/java -
HUP caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
INT caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
QUIT caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
ILL caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
TRAP default
ABRT default
EMT default
FPE caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
KILL default
BUS caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
SEGV caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
SYS default
PIPE ignored
ALRM default
TERM caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
USR1 caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VT
ALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+
2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
USR2 default
CLD default NOCLDSTOP
PWR default
WINCH default
URG default
POLL default
STOP default
TSTP default
CONT default
TTIN default
TTOU default
VTALRM default
PROF default
XCPU default
XFSZ default
WAITING ignored
LWP caught SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PRO
F,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+
3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
FREEZE default
THAW default
CANCEL caught SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PRO
F,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+
3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX
LOST default
RTMIN default
RTMIN+1 default
RTMIN+2 default
RTMIN+3 default
RTMAX-3 default
RTMAX-2 default
RTMAX-1 default
RTMAX default
-----
psig trace from in-loop start:
-----
$USER@$HOST:$HOME > for i in one; do ./start ; done
+ nohup $HOME/start2
Sending output to nohup.out
$USER@$HOST:$HOME > ps -ju $USER
PID PGID SID TTY TIME CMD
10589 10589 10589 pts/12 0:00 ksh
14021 10589 10589 pts/12 0:01 java
$USER@$HOST:$HOME > psig 14021
14021: $JAVA_HOME/bin/../bin/sparc/native_threads/java -
HUP caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
INT caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
QUIT caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
ILL caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
TRAP default
ABRT default
EMT default
FPE caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
KILL default
BUS caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
SEGV caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
SYS default
PIPE ignored
ALRM default
TERM caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
USR1 caught RESTART,SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
USR2 default
CLD default NOCLDSTOP
PWR default
WINCH default
URG default
POLL default
STOP default
TSTP ignored
CONT default
TTIN ignored
TTOU ignored
VTALRM default
PROF default
XCPU default
XFSZ default
WAITING ignored
LWP caught SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
FREEZE default
THAW default
CANCEL caught SIGINFO
HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD
,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FR
EEZE,THAW,CANCEL,LOST,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,
RTMAX
LOST default
RTMIN default
RTMIN+1 default
RTMIN+2 default
RTMIN+3 default
RTMAX-3 default
RTMAX-2 default
RTMAX-1 default
RTMAX default
------
Richard Russell
Deutsche Bank AG London
Global Markets Customer Solutions
Office: +44 (0)20 7545 8060
Mobile: +44 (0)79 0661 2237
DAUBIGNE Sebastien - BOR <sebastien.daubigne at atosorigin.com>
Sent by: sunhelp-bounces at sunhelp.org
11/22/2004 07:36 PM
Please respond to The SunHELP List
To: The SunHELP List <sunhelp at sunhelp.org>
cc:
Subject: RE: [SunHELP] for loop changes nohup?
Well, it seems that KSH (at least Solaris KSH) disable job control when
interpreting loops : If you truss the ksh process, you will see no trace
of
setpgrp() unlike without the for loop.
I don't know if it's a bug or a feature, or if it's POSIX compliant. For
instance, BASH, which is POSIX compliant, doesn't disable job control
inside
the loops : it creates a separate process group in all cases, so you can
play with ^Z/bg/fg.
Of course, ignoring SIGTSTP/SIGTTOU/SIGTTIN is a consequence of the job
control facility disabling.
Now for you java process killing, could you post the whole psig trace,
including the SIGHUP mask (maybe the sighup mask is reset to default by
the
java interpreter, which causes the "for loop" java process to be killed
when
the controlling terminal hangs up and send SIGHUP to the foreground
process
group, to which it belongs, unlike the "direct" one ?).
--
Sebastien DAUBIGNE
Sebastien.daubigne at atosorigin.com <
mailto:Sebastien.daubigne at atosorigin.com>
- +33(0)5.57.26.56.36
AtosOrigin Infogerance - IMS/ERP/Pessac
-----Message d'origine-----
De : sunhelp-bounces at sunhelp.org [mailto:sunhelp-bounces at sunhelp.org]De
la part de Richard Russell
Envoyi : lundi 22 novembre 2004 17:08
@ : The SunHELP List
Objet : RE: [SunHELP] for loop changes nohup?
I've simplified this further:
In one terminal (pts/17), I run `sleep 20`, then the following in the
second terminal (pts/12):
------------------------------------------------
$USER@$HOST:$HOME > ps -ju $USER
PID PGID SID TTY TIME CMD
10992 10992 10992 pts/12 0:00 ksh
19546 19546 20078 pts/17 0:00 sleep
20078 20078 20078 pts/17 0:01 ksh
$USER@$HOST:$HOME > psig 19546 > direct
------------------------------------------------
Then, the same thing , but running `for i in one; do sleep 20; done` in
the first terminal:
------------------------------------------------
$USER@$HOST:$HOME > ps -ju $USER
PID PGID SID TTY TIME CMD
10992 10992 10992 pts/12 0:00 ksh
20585 20078 20078 pts/17 0:00 sleep
20078 20078 20078 pts/17 0:01 ksh
$USER@$HOST:$HOME > psig 20585 > loop
$USER@$HOST:$HOME > diff direct loop
1c1
< 19546: sleep 20
---
> 20585: sleep 20
25c25
< TSTP default
---
> TSTP ignored
27,28c27,28
< TTIN default
< TTOU default
---
> TTIN ignored
> TTOU ignored
------------------------------------------------
Again, I would have expected this to work the other way around, if it was
different at all. Does anyone have any references that could explain this
behaviour? (the fact that a the for loop starts processes in the same
proces group, wheres starting the process directly starts it in a new
group?)
Cheers
Richard Russell
Deutsche Bank AG London
Global Markets Customer Solutions
Office: +44 (0)20 7545 8060
Mobile: +44 (0)79 0661 2237
"Richard Russell" <richard.russell+external at db.com>
Sent by: sunhelp-bounces at sunhelp.org
11/22/2004 03:42 PM
Please respond to The SunHELP List
To: The SunHELP List <sunhelp at sunhelp.org>
cc:
Subject: RE: [SunHELP] for loop changes nohup?
OK, looks promising...
`./start`:
----
> ps -ju $USER
PID PGID SID TTY TIME CMD
16402 16400 20078 pts/17 0:01 java
20078 20078 20078 pts/17 0:00 ksh
----
`for i in one; do ./start; done`
----
> ps -ju $USER
PID PGID SID TTY TIME CMD
11703 20078 20078 pts/17 0:01 java
20078 20078 20078 pts/17 0:00 ksh
----
... But why would a for loop start the process in the same group, whereas
the original command does it in a new group?
FYI I also discovered the psig command, ran it on the direct (./start) and
in_loop (for i in ...) processes, and diff'd the output:
----
> diff direct in_loop
1c1
< 10939: $JAVAHOME/bin/../bin/sparc/native_threads/java -
---
> 11703: $JAVAHOME/bin/../bin/sparc/native_threads/java -
25c25
< TSTP default
---
> TSTP ignored
27,28c27,28
< TTIN default
< TTOU default
---
> TTIN ignored
> TTOU ignored
---
Again, I fail to understand why the in_loop one would have different
responses to signals cf the direct one, and even here, it appears to
ignore more signals -- which seems opposite of what I expect given the
behaviour...
Richard Russell
Deutsche Bank AG London
Global Markets Customer Solutions
Office: +44 (0)20 7545 8060
Mobile: +44 (0)79 0661 2237
DAUBIGNE Sebastien - BOR <sebastien.daubigne at atosorigin.com>
Sent by: sunhelp-bounces at sunhelp.org
11/22/2004 03:14 PM
Please respond to The SunHELP List
To: The SunHELP List <sunhelp at sunhelp.org>
cc:
Subject: RE: [SunHELP] for loop changes nohup?
Here are some SIGHUP rules from
http://www.faqs.org/faqs/unix-faq/programmer/faq/.
I guess your problem is related to process group management (sh will
launch
the command in the same process group as the parent, as ksh will create a
separate process group).
Maybe you could send us the result from 'ps -ju $USER' which will print
session/process group leaders to help understand.
1.15 Why doesn't my process get SIGHUP when its parent dies?
============================================================
Because it's not supposed to.
`SIGHUP' is a signal that means, by convention, "the terminal line got
hung
up". It has nothing to do with parent processes, and is usually generated
by the tty driver (and delivered to the foreground process group).
However, as part of the session management system, there are exactly two
cases where `SIGHUP' is sent on the death of a process:
* When the process that dies is the session leader of a session that is
attached to a terminal device, `SIGHUP' is sent to all processes in
the foreground process group of that terminal device.
* When the death of a process causes a process group to become
orphaned,
and one or more processes in the orphaned group are *stopped*, then
`SIGHUP' and `SIGCONT' are sent to all members of the orphaned group.
(An orphaned process group is one where no process in the group has a
parent which is part of the same session, but not the same process
group.)
--
Sebastien DAUBIGNE
Sebastien.daubigne at atosorigin.com <
mailto:Sebastien.daubigne at atosorigin.com>
- +33(0)5.57.26.56.36
AtosOrigin Infogerance - IMS/ERP/Pessac
-----Message d'origine-----
De : sunhelp-bounces at sunhelp.org [mailto:sunhelp-bounces at sunhelp.org]De
la part de Richard Russell
Envoyi : lundi 22 novembre 2004 15:30
@ : The SunHELP List
Objet : Re: [SunHELP] for loop changes nohup?
OK, that makes a little more sense to me... but I can't see any difference
in the output of ptree, or in the ppid using ps... (again, with $USER,
$HOST, $HOME and $PATHTOJAVA replaced). Note that the scripts terminate
immediately after starting the java process, which again, makes me wonder
where the SIGTERM (or whichever SIG it is) is coming from... ie the
processes marked in braces ([]) terminate after starting the java process:
./start: ...
ksh [ --> sh --> nohup --> ksh --> nohup & --> ] java
for i in one; do ./start; done ...
ksh [ ( --> ksh subshell ) --> sh --> nohup --> ksh --> nohup & --> ] java
Here's some output of ptree and ps -o ppid,pid,args for each situation.
You can see that the parent PID of the java process is init...
----
$USER@$HOST:$HOME > ptree -a $USER
1 /etc/init -
3182 /usr/sbin/sshd
21419 /usr/sbin/sshd
21433 -ksh
14482 ptree -a $USER
$USER@$HOST:$HOME > ./start
+ nohup $HOME/start2
Sending output to nohup.out
$USER@$HOST:$HOME > ptree -a $USER
1 /etc/init -
3182 /usr/sbin/sshd
21419 /usr/sbin/sshd
21433 -ksh
14667 ptree -a $USER
14566 $PATHTOJAVA/bin/../bin/sparc/native_threads/java -cp . Slee
$USER@$HOST:$HOME > ps -p 14566 -o ppid,pid,args
PPID PID COMMAND
1 14566 $PATHTOJAVA/bin/../bin/sparc/native_threads/java -cp . Slee
$USER@$HOST:$HOME > ll ps -p 14566 -o ppid,pid,args
$USER@$HOST:$HOME > kill 14566
$USER@$HOST:$HOME > ptree -a $USER
1 /etc/init -
3182 /usr/sbin/sshd
21419 /usr/sbin/sshd
21433 -ksh
16682 ptree -a $USER
$USER@$HOST:$HOME > for i in 1; do ./start; done
+ nohup $HOME/start2
Sending output to nohup.out
$USER@$HOST:$HOME > ptree -a $USER
1 /etc/init -
3182 /usr/sbin/sshd
21419 /usr/sbin/sshd
21433 -ksh
16919 ptree -a $USER
16826 $PATHTOJAVA/bin/../bin/sparc/native_threads/java -cp . Slee
$USER@$HOST:$HOME > ps -p 16826 -o ppid,pid,args
PPID PID COMMAND
1 16826 $PATHTOJAVA/bin/../bin/sparc/native_threads/java -cp . Slee
$USER@$HOST:$HOME > kill 16826
$USER@$HOST:$HOME > ptree -a $USER
1 /etc/init -
3182 /usr/sbin/sshd
21419 /usr/sbin/sshd
21433 -ksh
17667 ptree -a $USER
----
Hence, I don't think that the signal is coming from the parent process. In
fact, I have a feeling that it has more to do with the terminal (eg
pts/26) closing than a signal... does closing a tty send signals anywhere?
Even if it does, it still doesn't explain why the for loop changes
anything... I have also tried adding output redirects on to the process,
but to no avail:
----
$USER@$HOST:$HOME
> more start2
#!/bin/ksh -x
nohup /data/fiplu1/users/tpuat11/java/bin/java -cp . Sleep 2>&1 >
/dev/null &
----
So, I'm still baffled...
Richard Russell
Deutsche Bank AG London
Global Markets Customer Solutions
Office: +44 (0)20 7545 8060
Mobile: +44 (0)79 0661 2237
velociraptor <velociraptor at gmail.com>
Sent by: sunhelp-bounces at sunhelp.org
11/22/2004 01:54 PM
Please respond to velociraptor; Please respond to The SunHELP List
To: The SunHELP List <sunhelp at sunhelp.org>
cc:
Subject: Re: [SunHELP] for loop changes nohup?
On Mon, 22 Nov 2004 10:33:14 +0000, Richard Russell
<richard.russell at db.com> wrote:
> Thanks -- my immediate thought on this is that it could explain the
> opposite behaviour more likely than what I actually see...
>
> ie you're suggesting this:
>
> ./start: ...
> ksh --> sh --> nohup --> ksh --> nohup & --> java
>
> for i in one; do ./start; done ...
> ksh ( --> ksh subshell ) --> sh --> nohup --> ksh --> nohup & --> java
>
> Why would exiting the ksh from the for loop example be more likely to
> cause the java process to exit than it would in the first example?
> Certainly, I would have expected that the nohup would catch the signals
> anyway, so a change at this point shouldn't affect the java process, but
> why would adding a subshell affect it?
>
> Then again, I've never really understood how signals propagate...
>
> Does anyone have any other ideas?
I think what Sheldon was implying that if the for loop is run in a
subshell,
any process spawned by that subshell will die when the parent pid dies.
So, when the for loop exits, it's child processes die as well. The
question
is, what signal does the shell send with it exits?
According to the man page, nohup only causes processes to ignore
SIGHUP and SIGQUIT. If you background the process it also ignores
interrupts. It doesn't prevent a SIGTERM from working.
I'd think you could test this by:
log in
log in from a second terminal
from within the first login shell:
run another shell process
then start your nohup script
in the second terminal:
do a ptree on the script
kill the pid of the login shell of your initial terminal session
But that still doesn't really test what signal is sent by a script's
subshell
exiting; I think you'll have to read up on ksh/sh.
What's the standard method for starting a process without it being a
child of the current process? Can you even do it from within a shell
script?
Regards--
=Nadine=
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist - SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp
More information about the SunHELP
mailing list