(diverging slightly)
On Fri, May 16, 2014 at 11:30 AM, Tilghman Lesher <[email protected]> wrote:
> On Fri, May 16, 2014 at 10:07 AM, Howard White <[email protected]> wrote:
>> Could someone give me a short course on why it is one executes these steps:
>>
>> ./configure as root
>> make as a user
>> make install as root
>>
>> ????
>>
>> I'm confused...
>>
>> Howard
>
> You don't necessarily need to run configure as root, but there are
> some tests, especially for daemons which start as root, which need the
> additional privileges to execute. For example, in Asterisk, I've
> written a test to check whether one may provide a bitfield longer than
> 1024 bits to the select(2) kernel call. This functionality is
> necessary to see if we can practically have more than 1024 file
> handles open, or if things would simply not work in that case. The
> problem is that you cannot have a file handle numbered greater than
> 1023 by default in any process, so you have to increase the available
> number of file handles in order to run that test.
I think that this case may have an unprivileged solution for most
users -- though it is a fine example of the idea of needing enhanced
capabilities in order to test kernel/system support!
By default, a process can have a maximum of files open as defined by:
/proc/sys/fs/file-max (or sysctl fs.file-max)
However, many environments include limitations enforced via resource
limits [ulimit(3)/*rlimits] for an interactive user process tree.
Bash (and pretty much every shell) can help check those with a simple:
> ulimit -nS # soft limit
1024
> ulimit -nH # hard limit
4096
A quick test with a sample program will show failure at fd 1023:
$ ./fds
fds: Failed! Last FD was 1023
Then the soft limit can be pushed up and we see it make it further:
$ ulimit -Sn `ulimit -Hn`
$ ./fds
fds: Failed! Last FD was 4095
So if I were writing a configure stanza for something like this, I
would check sysctl, then call getrlimit(RLIMIT_NOFILE,...) and tell
the user they need to either increase their limits before running
configure (e.g., via /etc/security/limits.conf or whatever) or run as
a privileged user that can override resource limit enforcement.
Alternatively, you can try the above hack to maximize the ulimit
setting and then only fail if that can't be done.
> I realize that is a very technical answer, but you have to understand
> the purpose of the test in order to understand why it's necessary
> sometimes to run as root.
It should be avoided if at all possible though!
hth,
will
~~ example source
/* gcc fds.c -o fds */
#include <err.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
int main(int argc, char **argv) {
int last = -1, fd;
while (1) {
fd = open("/dev/null", O_RDONLY);
if (fd < 0) errx(1, "Failed! Last FD was %d", last);
last = fd;
}
return 0;
}
--
--
You received this message because you are subscribed to the Google Groups
"NLUG" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nlug-talk?hl=en
---
You received this message because you are subscribed to the Google Groups
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
