Joey Hess <[email protected]> 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 ;-) */
+ }
return lim.rlim_cur;
#elif defined(_SC_OPEN_MAX)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
