'bash --login' spawned too many caused by job control on AIX 5.3
Hi, all: I configured with default and installed bash-4.2.45 on AIX 5.3 to my home directory. Each time I logged in, I used 'bash --login' to enter bash. Accidentally I sent SIGSTOP to the process of bash, then sent SIGCONT. Bash put the message 'There are running jobs' on screen, then forked too many processes that reached the AIX MAXUPROC limit. I tried to kill all the bash processes logged in as root, but without luck. I had to restart the server at the end. I guessed it did something with job control, so re-compiled bash with --disable-job-control. This time bash logged out normally. Seems like bash tries to spawn a logout child process when received a SIGCONT signal and prepared to exit, unfortunately logout child process forked another children and etc. ok, that's only my guess, and somehow it does not have the same problem on Linux. my bash vesion: bash --version GNU bash, version 4.2.45(1)-release (powerpc-ibm-aix5.3.0.0)
Re: 'bash --login' spawned too many caused by job control on AIX 5.3
On 9/24/13 2:54 AM, 李佳 wrote: > Seems like bash tries to spawn a logout child process when received a SIGCONT > signal and prepared to exit, unfortunately logout child process forked > another children and etc. ok, that's only my guess, and somehow it does not > have the same problem on Linux. It does not do this by default. If you have a .bash_logout file or a trap set on EXIT, bash may attempt to run processes when it exits. I suspect bash got -1/EIO when it tried to read from the terminal after the SIGCONT and exited as a result. 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: fc echoing DEBUG trap
On 9/19/13 2:12 PM, Carlos Pita wrote: > Bash Version: 4.2 > Patch Level: 45 > Release Status: release > > Description: > > If you set a DEBUG trap fc echoes it along the edited commands after > leaving editor. Sure: the DEBUG trap is supposed to be executed before every simple command (and a few other types). 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: fc echoing DEBUG trap
I see that, Chet. But it's not necessarily supposed to be echoed, that's what I'm saying. It's counterintuitive that fc prints the output. In fact, the output could very confusing. I have a complicated expression in the DEBUG trap that doesn't produce any output by itself, but this is what I see after calling fc, typing ls and leaving the editor: [carlos@netbook ~]$ fc ls [[ $BASH_COMMAND == "termic_hook @prompt" ]] || termic_hook "$BASH_COMMAND" get_profile $*) get_profile $* TERMIC_PROFILES $*) TERMIC_PROFILES $* basename $1) basename $1 TERMIC_PROFILES $base $*) TERMIC_PROFILES $base $* TERMIC_PROFILES $base) TERMIC_PROFILES $base Anki apps bin blog blog2 books down movies music node_modules notes post.html post.rst store tmp work "ls" is ok, the last line is expected, but my debug trap doesn't output what it's being listed in between, it's more like if I had "set -x". It's not even that the trap is being called recursively. Someone else got into this issue before: http://stackoverflow.com/questions/12363901/how-to-use-debug-trap-without-echoing-trap-command-in-fix-command Of course, it's possible to alias fc to reset the trap before calling the editor and restore after exiting, but it's a hack. On Tue, Sep 24, 2013 at 11:18 AM, Chet Ramey wrote: > On 9/19/13 2:12 PM, Carlos Pita wrote: > >> Bash Version: 4.2 >> Patch Level: 45 >> Release Status: release >> >> Description: >> >> If you set a DEBUG trap fc echoes it along the edited commands after >> leaving editor. > > Sure: the DEBUG trap is supposed to be executed before every simple > command (and a few other types). > > 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: fc echoing DEBUG trap
On 9/24/13 11:45 AM, Carlos Pita wrote: > I see that, Chet. But it's not necessarily supposed to be echoed, > that's what I'm saying. It's counterintuitive that fc prints the > output. In fact, the output could very confusing. OK. Here's how fc has worked historically: it internally turns on the -v option after running the editor and evaluates the contents of the resultant file. This is so you can see what happens to the edited commands. (It's an open question whether or not this should be -x instead, but it never has been.) The -v option doesn't discriminate between commands read from the input stream and commands executed by a trap. I assert that it's not counterintuitive -- it's the same thing that happens when you run the same commands from a prompt. 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/
