>>>> Bash on Linux seems to have problems starting subprocesses
>>>> occasionally, the following program fails randomly:
RW> ===8<=== CUT LOTS OF RUBBISH ===>8===
>>>> I've tested this on 2.2.6 2.2.6ac1 2.2.9 and 2.2.10ac10 with
>>>> bash versions 1.14 and 2.03. Machines tested were idle apart
>>>> from the shellscript, with plenty of RAM.
>>> This looks like a faulty test command to me - certainly, I was
>>> unable to get the script to fail...
>> If you was unable to get the YOUR script to fail and not initial
>> script then you basically tested wrong thing.
RW> May I congratulate you on your so-obvious twisting of what I said.
RW> Can I also repeat that I was unable to get EITHER script to fail on
RW> ANY of the kernels at my disposal. For reference, I tried 2.0.36,
RW> 2.0.37, 2.2.2, 2.2.5, 2.2.9 and 2.2.10 (all raw), and BOTH scripts
RW> worked perfectly under ALL kernels. Various RedHat 5.1, 5.2 and 6.0
RW> systems...
RW> I therefore REPEAT my statement as quoted above: The report looks like
RW> a faulty test command to me, rather than any fault in either bash or
RW> the kernel...
Since FIRST error message come from bash and NOT from test command it does not
look like problem with test command.
>>> Not sure what the problem is, but it's neither a kernel one nor
>>> a bash one...
>> OF COURSE ! When you removed the only thing which was tested
>> test will no longer fail fail for sure!!!
RW> True, but does that explain why the original script didn't fail
RW> either? You could try applying a bit of common sense before posting
RW> rubbish like this...
Since problem with fork/exec happens EXTREMALLY rare. I seen such problems
myself few times with real programs like login/pppd under 2.2 (when 2.0 works
flawlessly) but was unable to trigger it in controlled environment :-((
>> Terje: It failed to walk.
>> Riley: Walk is sooo slow, let change it to fly. See ? No
>> problems anymore...
RW> WHat sort of relationship is that supposed to bear to the subject
RW> under discussion?
There are something fishy in fork and/or exec in 2.2. Test was created to
trigger such problem (unsuccessfull for me, unfortunatelly). When you
"optimized" it with removal of fork/exec apparently out with the bathwater
went the baby (i.e. fork/exec in this case)...
>> P.S. Said this I must admit that I was unable to trigger problem
>> with initial script and kernel 2.2.2ac5, 2.2.5ac6 and 2.2.10ac10
>> here (under KSI-Linux 2.1 beta) so it really does not look like
>> kernel problem...
RW> Precicely my point...
Original poster said that BSD proccess accounting will help trigger the
problem but login was unable to execute pppd on perfectly idle system
without BSD process accounting :-(( It's sad that there are no way to
reproduce problem in controlled environment...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/