Re: RLIMIT_NOFILE fallback
- From
Jeff King <peff@peff.net>
- Date
- Dec 18, 2013, 19:17 UTC
- Message-ID
- <20131218191702.GA9083@sigill.intra.peff.net>
- In-Reply-To
- <xmqqy53ihwe4.fsf@gitster.dls.corp.google.com>
On Wed, Dec 18, 2013 at 10:00:35AM -0800, Junio C Hamano wrote:
Show 34 quoted lines
> 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