Re: bug in force_interactive handling
Hi Chet, thanks for taking a look.
28.12.2011 01:16, Chet Ramey wrote:
> On 12/26/11 10:12 AM, Stas Sergeev wrote:
>> Hi.
>>
>> It seems the -i switch of the bash doesn't work as expected
>> these days (I tried with bash-4.1).
> I'm not sure what `expected' means here; both code fragments are
> correct.
Lets get this double-checked.
>> I've found 2 places of the breakage.
>>
>> 1. initialize_job_control () has the following code:
>> ---
>> if (interactive == 0)
>> {
>> job_control = 0;
>> original_pgrp = NO_PID;
>> shell_tty = fileno (stderr);
>> }
>> else
>> {
>> shell_tty = -1;
>>
>> /* If forced_interactive is set, we skip the normal check that stderr
>> is attached to a tty, so we need to check here. If it's not, we
>> need to see whether we have a controlling tty by opening /dev/tty,
>> since trying to use job control tty pgrp manipulations on a non-tty
>> is going to fail. */
>> if (forced_interactive && isatty (fileno (stderr)) == 0)
>> ---
>>
>> But, -i sets "interactive_shell" variable, not "interactive", so the
>> aforementioned comment and code makes no sense, though it
>> might have been working in the past.
> `-i' sets the `forced_interactive' variable; look at flags.c. The shell
> sets interactive and interactive_shell internally. (And -i does end up
> setting `interactive'; look at shell.c:init_interactive() ).
-i does not end up setting `interactive' when used from the
script, see shell.c:init_interactive_script(). Sorry for not mentioning
initially that I am talking about the script, but I thought "-i" is
mainly useful for scripts.
So, after init_interactive_script() and "-i" we have
interactive==0, forced_interactive==1, interactive_shell==1.
With the code above, "forced_interactive" gets ignored.
Is this still not a bug?
> Job control isn't controlled by the `-i' option; it's the `-m' option.
> Interactive shells and shells with job control are not the same thing;
> you can have one without the other. A shell that would ordinarily
> be non-interactive (e.g., started to run a script, or as part of a
> pipeline) but is forced interactive using `-i' need not have job control
> enabled, though it usually will.
Why this "usually will" does not apply to the scripts?
The comments in the code clearly suggests this was the
case. Namely, they used to check "interactive_shell"
in waitchld() in the past, but now they check "job_control".
Have the bash changed its behaveor recently?
>> The result of this all is that if some script is being run with
>> "bash -i" and that script starts some binary, bash wouldn't honour
>> the SIGSTOP sent to that binary.
> What does `honour the SIGSTOP' mean here? If you want job control,
> try putting `set -m' into the script if $- doesn't include `m'.
Thanks: "set -m" together with "-i" kind of works...
The problem now is that bash thinks this job is stopped
forever, even after I send SIGCONT. Then it calls
terminate_stopped_jobs() to the running process... :(
Do you know how to solve this?
The test is simple:
---
#!/bin/bash -i
set -m; cat
echo Finished!
while :; do sleep 2; jobs; done
---
Send SIGSTOP to cat, then SIGCONT.
It is still displayed as "Stopped".
bash sends SIGHUP to disowned children in non-interactive mode
I'm experiencing some strange behaviour with bash and xterm or other X-terminals. I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release (i486-pc-linux-gnu)). To reproduce this, write a simple script like this: #!/bin/bash (xclock &) sleep 15 Then run it with xterm -e. xclock is not a child of xterm or bash (PPID=1) because it was invoked with "(xclock &)": F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 S turin23318 1 0 80 0 - 2292 - 17:52 pts/1 00:00:00 xclock Yet xclock closes when the script exits because it receives a SIGHUP. Just strace the PID: Process 23318 attached - interrupt to quit restart_syscall(<... resuming interrupted call ...>) = ? ERESTART_RESTARTBLOCK (To be restarted) --- SIGHUP (Hangup) @ 0 (0) --- Process 23318 detached This should not happen or am I wrong? If you change the header in the script to #!/bin/tcsh or #!/bin/csh xclock does not receive a SIGHUP. Therefore I assume the problem is with bash. Same with disown: #!/bin/bash xclock & disown -a sleep 15 Changeing the header to "#!/bin/bash -i" doesn't make a difference either. If I execute the script in an interactive terminal and close the terminal window with the "x" button after the script finished xclock stays open. No SIGHUP. Why is a HUP signal send in the other case? Any ideas? Am i missing something? regards SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! [1]http://f.web.de/?mc=021192 References 1. http://f.web.de/?mc=021192
Re: bash sends SIGHUP to disowned children in non-interactive mode
On Wed, Dec 28, 2011 at 07:44:40PM +0100, ck...@web.de wrote: >(xclock &) >Yet xclock closes when the script exits because it receives a SIGHUP. If you want a process to ignore a signal, you should either use nohup(1), or ignore the signal yourself using a trap and then exec it.
Re: bash sends SIGHUP to disowned children in non-interactive mode
On Wed, Dec 28, 2011 at 01:47:47PM -0500, Greg Wooledge wrote: > On Wed, Dec 28, 2011 at 07:44:40PM +0100, ck...@web.de wrote: > >(xclock &) > > >Yet xclock closes when the script exits because it receives a SIGHUP. > > If you want a process to ignore a signal, you should either use nohup(1), > or ignore the signal yourself using a trap and then exec it. You could also "disown -h" it and avoid that the signal is sent at all. This is especially helpful, if a program resets its signal handlers (e.g. xemacs?).
Re: bash sends SIGHUP to disowned children in non-interactive mode
>You could also "disown -h" it and avoid that the signal is sent at all. >This is especially helpful, if a program resets its signal handlers >(e.g. xemacs?). What I am saying is, this is not working! Please try if you can reproduce what I wrote. If so try to use disown -h. Doesn't make a difference. >If you want a process to ignore a signal, you should either use nohup(1), >or ignore the signal yourself using a trap and then exec it. I know about nohup but I don't want to ignore a SIGHUP. My point is that there is a SIGHUP sent although it shouldn't. Or can you explain why this signal is being send in the first place? regards SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! [1]http://f.web.de/?mc=021192 References 1. http://f.web.de/?mc=021192
Re: bash sends SIGHUP to disowned children in non-interactive mode
On Wed, Dec 28, 2011 at 08:37:38PM +0100, ck...@web.de wrote: >>You could also "disown -h" it and avoid that the signal is sent at >all. >>This is especially helpful, if a program resets its signal handlers >>(e.g. xemacs?). >What I am saying is, this is not working! >Please try if you can reproduce what I wrote. >If so try to use disown -h. Doesn't make a difference. If you want to disown something, you have to *stop* doing this double-fork nonsense. #!/bin/bash set -m xterm & disown -h Do not put (...) around the background job. When you do that, the main bash process loses its parenthood over the xterm process, so it won't be able to manage it. I'm not 100% sure if the set -m will be required to enable "disown" to work, but I'd try it that way.
Re: bash sends SIGHUP to disowned children in non-interactive mode
On 12/28/11 1:44 PM, ck...@web.de wrote: >I'm experiencing some strange behaviour with bash and xterm or other >X-terminals. >I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release >(i486-pc-linux-gnu)). >To reproduce this, write a simple script like this: >#!/bin/bash >(xclock &) >sleep 15 >Then run it with xterm -e. >xclock is not a child of xterm or bash (PPID=1) because it was invoked >with "(xclock &)": >F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY >TIME CMD >0 S turin23318 1 0 80 0 - 2292 - 17:52 pts/1 >00:00:00 xclock >Yet xclock closes when the script exits because it receives a SIGHUP. It may receive a SIGHUP, but you haven't demonstrated that it's bash sending the SIGHUP. Since job control isn't enabled, it's most likely that the SIGHUP xterm sends to the process group when you hit the close button gets to xclock because it's in the same process group as bash. Bash only sends SIGHUP to running jobs of an interactive login shell when the `huponexit' option is set. It will resend SIGHUP to running jobs if they haven't been disowned, but the background-process-inside-a-subshell business means xclock isn't a child process or job of the shell anyway. You might strace the bash process that runs the script inside the xterm to see what it does. I traced an instance of both scripts (above and below) on an Ubuntu 10 system with bash-4.2.10 and didn't see any sign that bash sent a SIGHUP, even when I used the close button on the xterm (in which case bash received the SIGHUP). >Just strace the PID: >Process 23318 attached - interrupt to quit >restart_syscall(<... resuming interrupted call ...>) = ? >ERESTART_RESTARTBLOCK (To be restarted) >--- SIGHUP (Hangup) @ 0 (0) --- >Process 23318 detached >This should not happen or am I wrong? >If you change the header in the script to #!/bin/tcsh or #!/bin/csh >xclock does not receive a SIGHUP. Because csh sets SIGHUP to SIG_IGN in asynchronous children. Bash doesn't. >Therefore I assume the problem is with bash. >Same with disown: >#!/bin/bash >xclock & >disown -a >sleep 15 >Changeing the header to "#!/bin/bash -i" doesn't make a difference >either. >If I execute the script in an interactive terminal and close the >terminal window with the "x" button after the script finished xclock >stays open. >No SIGHUP. Why is a HUP signal send in the other case? Any ideas? Am i >missing something? I suspect that it's the difference between job control and no job control, but without knowing exactly which process sent the SIGHUP there isn't enough information to say for sure. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash sends SIGHUP to disowned children in non-interactive mode
Am Wed, 28 Dec 2011 14:48:45 -0500 schrieb Greg Wooledge : > > If you want to disown something, you have to *stop* doing this double-fork > nonsense. > > #!/bin/bash > set -m > xterm & > disown -h > > Do not put (...) around the background job. When you do that, the main > bash process loses its parenthood over the xterm process, so it won't be > able to manage it. > > I'm not 100% sure if the set -m will be required to enable "disown" to work, > but I'd try it that way. > That "double-fork nonsense" was just to ensure that the forked process was not a child of the shell. And I still don't understand why it sends a SIGHUP to such a process on exit. Or maybe I do now.. The 'set -m' is exactly what is needed for everything to work. Then disown works as expected and so does the double-fork. Without 'set -m' neither of the two ways work properly. I thought if the header #!/bin/bash -i is used that includes job management? Maybe that's the bug Stas Sergeev is talking about in the previous thread? Well, thanks a lot for the input. I thought I had job management covered with the "-i" flag. best regards
Re: bash sends SIGHUP to disowned children in non-interactive mode
> It may receive a SIGHUP, but you haven't demonstrated that it's bash > sending the SIGHUP. Since job control isn't enabled, it's most likely > that the SIGHUP xterm sends to the process group when you hit the close > button gets to xclock because it's in the same process group as bash. > > Bash only sends SIGHUP to running jobs of an interactive login shell when > the `huponexit' option is set. It will resend SIGHUP to running jobs > if they haven't been disowned, but the background-process-inside-a-subshell > business means xclock isn't a child process or job of the shell anyway. Yes that why used that background-process-inside-a-subshell because I thought is was a good way to make sure that it won't be a job of the shell. I didn't get anywhere with the strace yet but figured out (thanks to you and Greg) that I get a different behavior with job control enabled. So let's take these two scripts, clock1.sh and clock2.sh. I know it sounds boring but please bear with me. - #!/bin/bash set -m xclock & sleep 2 -- #!/bin/bash -i xclock & sleep 2 -- I run them with: xterm -hold -e './clock1.sh' the -hold keeps the xterm window open after the scripts finish. The first script works fine, xclock stays. I don't even have to disown. The second script, xclock appears and disappears after 2 seconds. Received a SIGHUP when the script ended. The xterm window is still there because of the -hold parameter. I get the exact same behavior if I use "(xclock &)" instead. So without job control bash might (I know, we don't know for sure) send the SIGHUP to all processes started in the shell, whether child by definition or not? Shouldn't the -i flag enable job control by the way? Regards, Philip
bash sends SIGHUP to disowned children in non-interactive mode
I'm experiencing some strange behaviour with bash and xterm or other X-terminals. I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release (i486-pc-linux-gnu)). To reproduce, write a simple script like this: #!/bin/bash (xclock &) sleep 15 Then run it with xterm -e. xclock is not a child of xterm or bash (PPID=1) because it was invoked with "(xclock &)": F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 S turin23318 1 0 80 0 - 2292 - 17:52 pts/1 00:00:00 xclock Yet xclock closes when the script exits because it receives a SIGHUP. Just strace the PID: Process 23318 attached - interrupt to quit restart_syscall(<... resuming interrupted call ...>) = ? ERESTART_RESTARTBLOCK (To be restarted) --- SIGHUP (Hangup) @ 0 (0) --- Process 23318 detached If you change the header in the script to #!/bin/tcsh or #!/bin/csh xclock does not receive a SIGHUP. Therefore I assume the problem is with bash. Same with disown: #!/bin/bash xclock & disown -a sleep 15 If I execute the script in an interactive terminal and close the windows with the "x" button after the script finished xclock stays open. No SIGHUP. So where is that SIGHUP coming from in the other case? Any ideas? Am i missing something? regards SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! [1]http://f.web.de/?mc=021192 References 1. http://f.web.de/?mc=021192
