|
a/src/utils/closefrom.cpp |
|
b/src/utils/closefrom.cpp |
|
... |
|
... |
| 23 |
* The only descriptors closed are those on which the FD_CLOEXEC flag was
|
23 |
* The only descriptors closed are those on which the FD_CLOEXEC flag was
|
| 24 |
* set. FD_CLOEXEC is not easily usable on files opened by external
|
24 |
* set. FD_CLOEXEC is not easily usable on files opened by external
|
| 25 |
* libraries.
|
25 |
* libraries.
|
| 26 |
*
|
26 |
*
|
| 27 |
* There are many reasons for closing file descriptors before
|
27 |
* There are many reasons for closing file descriptors before
|
| 28 |
* an exec (security, pipe control, the possibility that a bug will trigger
|
28 |
* an exec (security, pipe control, the possibility that a bug will
|
| 29 |
* an unwanted write, etc.)
|
29 |
* trigger an unwanted write, etc.)
|
| 30 |
*
|
30 |
*
|
| 31 |
* A process has currently no POSIX way to determine the set of open file
|
31 |
* A process has currently no POSIX way to determine the set of open file
|
| 32 |
* descriptors or at least the highest value. Closing all files (except a few),
|
32 |
* descriptors or at least the highest value. Closing all files (except a few),
|
| 33 |
* thus implies performing a close() system call on each entry up to the
|
33 |
* thus implies performing a close() system call on each entry up to the
|
| 34 |
* maximum, which can be both relatively difficult to determine, and quite
|
34 |
* maximum, which can be both relatively difficult to determine, and quite
|
|
... |
|
... |
| 52 |
*
|
52 |
*
|
| 53 |
* Solaris:
|
53 |
* Solaris:
|
| 54 |
* - Solaris 10+ has closefrom, and can specify closefrom to posix_spawn()
|
54 |
* - Solaris 10+ has closefrom, and can specify closefrom to posix_spawn()
|
| 55 |
*
|
55 |
*
|
| 56 |
* Linux:
|
56 |
* Linux:
|
| 57 |
* - Has nothing. The method we used (opening /dev/fd) was very
|
57 |
* - Has nothing. The method we initially used (listing /dev/fd) could
|
| 58 |
* unsafe in multithread fork/exec context. We now use a close()
|
58 |
* deadlock in multithread fork/exec context. We now use a close()
|
|
|
59 |
* loop but there is no completely reliable way to determine the high limit.
|
| 59 |
* loop. glibc maintainers think that closefrom() is a bad idea
|
60 |
* glibc maintainers think that closefrom() is a bad idea
|
| 60 |
* *especially* because it is implemented on *BSD and Solaris. Go
|
61 |
* *especially* because it is implemented on *BSD and Solaris. Go
|
| 61 |
* figure...: https://sourceware.org/bugzilla/show_bug.cgi?id=10353
|
62 |
* figure...: https://sourceware.org/bugzilla/show_bug.cgi?id=10353
|
| 62 |
*
|
63 |
*
|
| 63 |
* Interface:
|
64 |
* Interface:
|
| 64 |
*
|
65 |
*
|
|
... |
|
... |
| 204 |
}
|
205 |
}
|
| 205 |
return 0;
|
206 |
return 0;
|
| 206 |
}
|
207 |
}
|
| 207 |
#endif
|
208 |
#endif
|
| 208 |
|
209 |
|
|
|
210 |
// Note that this will not work if the limit was lowered after a
|
|
|
211 |
// higher fd was opened. But we don't call setrlimit() inside recoll
|
|
|
212 |
// code, so we should be ok. It seems that sysconf(_SC_OPEN_MAX)
|
|
|
213 |
// usually reports the soft limit, so it's redundant, but it could be
|
|
|
214 |
// useful in case getrlimit() is not implemented (unlikely as they're
|
|
|
215 |
// both POSIX.1-2001?
|
| 209 |
int libclf_maxfd(int)
|
216 |
int libclf_maxfd(int)
|
| 210 |
{
|
217 |
{
|
| 211 |
struct rlimit lim;
|
218 |
struct rlimit lim;
|
| 212 |
getrlimit(RLIMIT_NOFILE, &lim);
|
219 |
getrlimit(RLIMIT_NOFILE, &lim);
|
| 213 |
return int(lim.rlim_cur);
|
220 |
return int(lim.rlim_cur);
|