Re: RLIMIT_NOFILE fallback

[Jeff King <peff@peff.net>]

On Wed, Dec 18, 2013 at 10:00:35AM -0800, Junio C Hamano wrote:

> Joey Hess <joey@kitenet.net> writes:
> 
> > In sha1_file.c, when git is built on linux, it will use 
> > getrlimit(RLIMIT_NOFILE). I've been deploying git binaries to some
> > unusual systems, like embedded NAS devices, and it seems some with older
> > kernels like 2.6.33 fail with "fatal: cannot get RLIMIT_NOFILE: Bad address".
> >
> > I could work around this by building git without RLIMIT_NOFILE defined,
> > but perhaps it would make sense to improve the code to fall back
> > to one of the other methods for getting the limit, and/or return the
> > hardcoded 1 as a fallback. This would make git binaries more robust
> > against old/broken/misconfigured kernels.
> 
> Hmph, perhaps you are right.  Like this?
> 
>  sha1_file.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/sha1_file.c b/sha1_file.c
> index daacc0c..a3a0014 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -809,8 +809,12 @@ static unsigned int get_max_fd_limit(void)
>  #ifdef RLIMIT_NOFILE
>  	struct rlimit lim;
>  
> -	if (getrlimit(RLIMIT_NOFILE, &lim))
> -		die_errno("cannot get RLIMIT_NOFILE");
> +	if (getrlimit(RLIMIT_NOFILE, &lim)) {
> +		static int warn_only_once;
> +		if (!warn_only_once++)
> +			warning("cannot get RLIMIT_NOFILE: %s", strerror(errno));
> +		return 1; /* see the caller ;-) */
> +	}

I wish we understood why getrlimit was failing. Returning EFAULT seems
like an odd choice if it is not implemented for the system. On such a
system, do the other fallbacks actually work? Would it work to do:

diff --git a/sha1_file.c b/sha1_file.c
index daacc0c..ab38795 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -809,11 +809,11 @@ static unsigned int get_max_fd_limit(void)
 #ifdef RLIMIT_NOFILE
 	struct rlimit lim;
 
-	if (getrlimit(RLIMIT_NOFILE, &lim))
-		die_errno("cannot get RLIMIT_NOFILE");
+	if (!getrlimit(RLIMIT_NOFILE, &lim))
+		return lim.rlim_cur;
+#endif
 
-	return lim.rlim_cur;
-#elif defined(_SC_OPEN_MAX)
+#if defined(_SC_OPEN_MAX)
 	return sysconf(_SC_OPEN_MAX);
 #elif defined(OPEN_MAX)
 	return OPEN_MAX;

That is, does sysconf actually work on such a system (or does it need a
similar run-time fallback)? And either way, we should try falling back
to OPEN_MAX rather than 1 if we have it.

As far as the warning, I am not sure I see a point. The user does not
have any useful recourse, and git should continue to operate as normal.
Having every single git invocation print "by the way, RLIMIT_NOFILE does
not work on your system" seems like it would get annoying.

-Peff