Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 24 Jul 1999 06:59:06 +0400 (MSD) | Subject | Re: fork or exec thingy. |
| |
In <Pine.LNX.4.10.9907240039100.12686-100000@ps.cus.umist.ac.uk> Riley Williams (rhw@memalpha.cx) wrote: RW> Hi Khimenko.
>>>> 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/
| |