On Fri, May 16, 2014 at 1:54 PM, Will Drewry <[email protected]> wrote: > (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)
This only works on Linux. Configure scripts are typically designed to run on multiple platforms, not always Linux. In fact, one of the guidelines for writing configure tests is to ALWAYS test the actual functionality you seek, rather than trying to grab system versions and attempting to extrapolate from there. Thus, it's better to increase the limit to some value beyond any standard limit and attempt to use that. > 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 What platform are you doing this on? I just tried it on Ubuntu 12.04 and those extensions to ulimit don't work. > 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. Another alternative (which we've done in Asterisk, due to the need to run on cross-compiled architectures) is to delay the test until runtime and decline to run if the support is lacking. -- Tilghman -- -- 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.
