Re: bin/44722

[Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>]

The following reply was made to PR bin/44722; it has been noted by GNATS.

From: Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
pooka%iki.fi@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> 
wrote:
 
 > =A0On Sat, 17 Sep 2011, Abhinav Upadhyay wrote:
 > =A0> Not only ls(1) but probably a number of other programs are not behav=
 ing
 > =A0> correclty under low file descriptor limit.
 > =A0> For example:
 > =A0>
 > =A0> $ man ls
 > =A0> .: 4: Invalid argument
 >
 > =A0I can't replicate that. =A0I get the following results, with everythin=
 g
 > =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=
 er
 > =A0> error messages if I tried to do something like this:
 > =A0>
 > =A0> $ . ls #supply name of any executable file
 > =A0> .: Cannot execute ELF binary /bin/ls
 > =A0>
 > =A0> $ ls
 > =A0> ls: .: Too many open files
 > =A0>
 > =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.
 
 --
 Abhinav