Solaris 9 - nohup'd background child process dying when ^C pressed in parent (/sbin/sh)
Sean O'Neill
a process, and then hit ^C at the command line why the background
child process dies ?
If I exec /bin/ksh, this doesn't occur.
--
........................................................
......... ..- -. .. -..- .-. ..- .-.. . ... ............
.-- .. -. -... .-.. --- .-- ... -.. .-. --- --- .-.. ...
Sean O'Neill
se...@deletethistorespond.seanoneill.deletethistorespond.info
Darren Dunham
> Anyone know why when using /sbin/sh as the shell, you nohup background
> a process, and then hit ^C at the command line why the background
> child process dies ?
/bin/sh and /sbin/sh have no job control. Although you can start a job
in the background, most of the structures that make that useful are not
present in that shell.
Likely all the work that job control does (like starting new process
groups) is missing, and the signal is delivered to the entire group.
> If I exec /bin/ksh, this doesn't occur.
That shell (and every other one besides /(s)bin/sh that I'm aware of)
has job control built in.
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Sean O'Neill
<ddu...@redwood.taos.com> wrote:
>Sean O'Neill <se...@deletethistorespond.seanoneill.deletethistorespond.info> wrote:
>> Anyone know why when using /sbin/sh as the shell, you nohup background
>> a process, and then hit ^C at the command line why the background
>> child process dies ?
>
>/bin/sh and /sbin/sh have no job control. Although you can start a job
>in the background, most of the structures that make that useful are not
>present in that shell.
>
>Likely all the work that job control does (like starting new process
>groups) is missing, and the signal is delivered to the entire group.
>
>> If I exec /bin/ksh, this doesn't occur.
>
>That shell (and every other one besides /(s)bin/sh that I'm aware of)
>has job control built in.
Kewl ... thanks for the reply.
Neil W Rickert
>/bin/sh and /sbin/sh have no job control. Although you can start a job
>in the background, most of the structures that make that useful are not
>present in that shell.
That cannot be quite right. Since "jsh" has job control, and is the
same binary as "sh", the structures must be there (even if not
activated).
Sean O'Neill
wrote:
You brought up a good point. I haven't tested this with /usr/bin/sh.
I'll give it a try.
Sean O'Neill
wrote:
>Darren Dunham <ddu...@redwood.taos.com> writes:
Interesting - I'm not sure what the correct true answer is (e.g. job
control vs no job control or whatever) but /sbin/sh and /usr/bin/sh
show the same behavior - a control-c in the parent process terminates
a backgrounded child process even one that has been nohup'd.
/usr/bin/jsh (same as binary as /usr/bin/sh), /usr/bin/ksh, and
/usr/bin/tcsh (didn't try any others) don't show this behavior.
IMHO - one more reason to change root's shell - either by modifying
/etc/passwd or something in .profile or "exec <whatever>" - I do the
latter by default.
Wayne Pollock
not SIGHUP (1), right?. I think that nohup starts sh to
run your command, after trap-ing SIGHUP. I bet you can write a
"noint" program that ignores SIGINT and then starts you program,
just like nohup ignores SIGHUP. It would probably be better in C,
but I'm willing to be laughed at:
cat >noint <<!
trap '' 2
sh "$@"
!
chmod 755 noint
noint some-interesting-command &
Try "noint sleep 10 &", and then try ^C and see if that
solves the problem.
I don't remember this issue on other Unix systems I've used,
maybe it is a problem in the Solaris version of the statically
linked shell (/sbin/sh).
I remember a funny story about one reason why the Bourne
shell is so long lasting, without suffering lots of
modifications over the years. It seems Steve Bourne was
a novice C programmer but experienced in PL/1. The story
is that Steve use #define macros to make C look a lot like
PL/1, with the result that no other programmers could
make heads or tails of his source code and were afraid
to touch it. Don't know if this is true though.
-Wayne
Casper H.S. Dik
>Interesting - I'm not sure what the correct true answer is (e.g. job
>control vs no job control or whatever) but /sbin/sh and /usr/bin/sh
>show the same behavior - a control-c in the parent process terminates
>a backgrounded child process even one that has been nohup'd.
>/usr/bin/jsh (same as binary as /usr/bin/sh), /usr/bin/ksh, and
>/usr/bin/tcsh (didn't try any others) don't show this behavior.
^C is not "in the parent shell"; ^C is send to the foreground process
group on the terminal.
A shell without job control doesn't create new process groups for
all pipelines started:
% sh
$ sleep 20 &
18226
$ ps -j
PID PGID SID TTY TIME CMD
18226 18225 18215 pts/8 0:00 sleep
18215 18215 18215 pts/8 0:00 tcsh
18225 18225 18215 pts/8 0:00 sh
18230 18225 18215 pts/8 0:00 ps
$ ^D
% ksh
ksh
$ sleep 20&
[1] 18232
$ ps -j
PID PGID SID TTY TIME CMD
18231 18231 18215 pts/8 0:00 ksh
18215 18215 18215 pts/8 0:00 tcsh
18232 18232 18215 pts/8 0:00 sleep
18233 18233 18215 pts/8 0:00 ps
As you can see, the children of ksh all have different process group
ids; the children of sh all have the same process group.
The question is why nohup'ed processes don't ignore SIGINT; "psig"
seems to suggest they do.
>IMHO - one more reason to change root's shell - either by modifying
>/etc/passwd or something in .profile or "exec <whatever>" - I do the
>latter by default.
Don't mention root's shell!
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Chris Thompson
Indeed, although it's not documented, one can go "set -m" to turn on
job control dynamically, or "set +m" to turn it off.
Chris Thompson
Email: cet1 [at] cam.ac.uk
Karl & Betty Schendel
wrote:
> [snip]
> I remember a funny story about one reason why the Bourne
> shell is so long lasting, without suffering lots of
> modifications over the years. It seems Steve Bourne was
> a novice C programmer but experienced in PL/1. The story
> is that Steve use #define macros to make C look a lot like
> PL/1, with the result that no other programmers could
> make heads or tails of his source code and were afraid
> to touch it. Don't know if this is true though.
The bit about the #define macros is true enough. I remember seeing
the bourne shell source, years ago, and while it didn't look all that
much like C, it was certainly comprehensible to anyone above bozo level.
I never felt any great urge to change it, so I can't say whether
the code was easy to modify or hard.
Karl
Sean O'Neill
wrote:
Ahhhh Casper I was hoping you would step in here. Thanks very much :)
>>IMHO - one more reason to change root's shell - either by modifying
>>/etc/passwd or something in .profile or "exec <whatever>" - I do the
>>latter by default.
>
>Don't mention root's shell!
Yeah, I know not trying to start a flame war but my issues in this
topic are with the root shell actually. I also have worked on a
project where something VERY similar was happening with Weblogic and
how it was started as root under /sbin/sh. They would log out and
Weblogic would immediately die. I remember someone saying the issue
was with Java not handling certain signals right but this discussion
seems pretty close to the topic.
Anyway, thanks for the explanation.
Goran Larsson
> I remember a funny story about one reason why the Bourne
> shell is so long lasting, without suffering lots of
> modifications over the years.
It has had quite a number of modifications over the years. It is probably
so long lasting because so many shell scripts have been written for it.
> It seems Steve Bourne was
> a novice C programmer but experienced in PL/1. The story
> is that Steve use #define macros to make C look a lot like
> PL/1, with the result that no other programmers could
> make heads or tails of his source code and were afraid
> to touch it. Don't know if this is true though.
I don't know about the "novice C programmer" part, but the original
Bourne shell I have seen was riddled with weird macros trying to make
C look like Algol. David G. Korn called it an "an Algol-like variant
of C". The Algol part is also visible to the user as the Algol-esque
"if fi" and "case esac" keyword pairs. Modern Bourne shells (the last
20 years or so) are written in normal C. More history of early Unix
shells here:
< http://www.uni-ulm.de/~s_smasch/various/bourne/korn.html >
--
Göran Larsson http://www.mitt-eget.com
John D Groenveld
>project where something VERY similar was happening with Weblogic and
>how it was started as root under /sbin/sh. They would log out and
>Weblogic would immediately die. I remember someone saying the issue
You should immediately investigate why you need to run Weblogic as root.
Doesn't that scare the crap out of you?
John
groe...@acm.org
Sean O'Neill
wrote:
Unfortunately I'm on the operations side of the house - I've tried
explaining the the developer GOOFS why this is a HORRIBLY bad idea but
things were already setup this way when I joined the project. I've
jumped up and down on management's face on this already - waiting to
see what they are going to do.
Philip Brown
deletethistorespond.info wrote:
>...
>Yeah, I know not trying to start a flame war but my issues in this
>topic are with the root shell actually. I also have worked on a
>project where something VERY similar was happening with Weblogic and
>how it was started as root under /sbin/sh.
conciencious admins write clean startup scripts for things, rather than
complaining about root's default shell not being conducive to starting
random demons.
> They would log out and Weblogic would immediately die.
for that matter, neither do they give application developers root shells.
that's what "sudo /etc/init.d/weblogic start" is for.
(or whatever the RBAC equivalent is. I forget the syntax, 'cause its not
as convenient)
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
http://www.spamlaws.com/state/ca1.html
Sean O'Neill
Brown) wrote:
>On Tue, 09 Jul 2002 15:09:37 GMT, se...@deletethistorespond.seanoneill.
>deletethistorespond.info wrote:
>>...
>>Yeah, I know not trying to start a flame war but my issues in this
>>topic are with the root shell actually. I also have worked on a
>>project where something VERY similar was happening with Weblogic and
>>how it was started as root under /sbin/sh.
>
>conciencious admins write clean startup scripts for things, rather than
>complaining about root's default shell not being conducive to starting
>random demons.
Its not a complaint - sorry you took that way - my wording does convey
that though. I did learned something in the thread about /sbin/sh and
how it operates in relation to background jobs.
>conciencious admins write clean startup scripts for things, rather than
Irregardless of the "starting as root" issue, a nohup is used in the
startup script and does not prevent the process from dying. Can you
explain that ?
>for that matter, neither do they give application developers root shells.
>
>that's what "sudo /etc/init.d/weblogic start" is for.
>
Funny, I said the same thing and I got a blank stare back.
Philip Brown
deletethistorespond.info wrote:
>
>Irregardless of the "starting as root" issue, a nohup is used in the
>startup script and does not prevent the process from dying. Can you
>explain that ?
nohup is a wierd critter anyways.
When i *really* want something to be in the background, and the "something"
wasnt designed to be a demon (automatically disassociating itself from
the controlling tty, etc), then I tend to put a csh wrapper around it.
'bout the only time I ever use csh :-)
>>that's what "sudo /etc/init.d/weblogic start" is for.
>
>
>Funny, I said the same thing and I got a blank stare back.
Just remember, according to the law, silence implies consent :-)