On Wed, Dec 18, 2013 at 10:00:35AM -0800, Junio C Hamano wrote:
> Joey Hess <j...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
