[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
The following reply was made to PR bin/44722; it has been noted by GNATS.
From: Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
Subject: Re: bin/44722
Date: Sun, 18 Sep 2011 16:24:59 +0530
On Sun, Sep 18, 2011 at 2:45 PM, Alan Barrett <apb%cequrux.com@localhost>
> =A0On Sat, 17 Sep 2011, Abhinav Upadhyay wrote:
> =A0> Not only ls(1) but probably a number of other programs are not behav=
> =A0> correclty under low file descriptor limit.
> =A0> For example:
> =A0> $ man ls
> =A0> .: 4: Invalid argument
> =A0I can't replicate that. =A0I get the following results, with everythin=
> =A0either working or giving a reasonable error:
I also see man(1) working properly if I use the above script. But I
did something like this:
$ ulimit -n 5
$ man ls
.: 4: Invalid argument
Fair enough. I didn't perform a thorough enough check like you did,
most probably my environment had to do something with the weird
results I got.
> =A0> It was even more weird to see that ls(1) and man(1) exited with prop=
> =A0> error messages if I tried to do something like this:
> =A0> $ . ls #supply name of any executable file
> =A0> .: Cannot execute ELF binary /bin/ls
> =A0> $ ls
> =A0> ls: .: Too many open files
> =A0Those error messages seem reasonable to me.
My point with the above example was that, if you have a low file
descriptor limit, then ls(1) lists all the sub-directories, but if you
execute the above set of commands sequentially, ls(1) does give a sane
message and exits. Probably man(1) is irrelevant here. I mixed it up.
Main Index |
Thread Index |