| Summary: | Cherokee ulimit problem (make default ulimit settings consistent across applications) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ikke <eikke> |
| Component: | [OLD] Server | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | www-servers+disabled |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ikke
2005-04-17 12:10:16 UTC
Last time I checked the gentoo default for ulimit was unlimited and I'm quite sure nobody changed it. I must add this is a Gentoo Hardened system. The error message I quoted comes straight from /var/log/messages (and is repeated 1000th times due to the webservers, sshd,... trying to access files), some people told me this is a ulimit problem. After I sent a mail regarding this issue to the cherokee mailing list, the cherokee author contacted me and we'll work together to try to solve this problem, because what happens here (cherokee keeping 1000s of files opened) should not happen at all. I'll try to keep you updated. Even after setting the MaxFds value in advanced.conf, it opened more than 4096 (the value I chose) files. http://www.0x50.org/archive/2005-April/000649.html could be a starting place for more information The default rlimit on open files is set to 1024 and not 11615. cheap pax-utils # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4095 virtual memory (kbytes, -v) unlimited You can enforce soft and hard ulimits or change the defaults on the user end in a number of ways. /etc/limits, enforce rlimit on execve() via grsec, PAM, outright setting them in /etc/conf.d/* on a per service basis and many other well known unix ways. This bug is also misassigned to base-system@ solar@simple mjpegtools $ epkginfo cherokee Package: www-servers/cherokee Herd: www-servers Maintainer: www-servers Keywords: cherokee-0.4.5: ~sparc Keywords: cherokee-0.4.16: ~x86 Keywords: cherokee-0.4.17.1: ppc x86 ChangeLog: 7 bass, 4 pvdabeel, 4 stuart, 3 aliz, 2 agriffis, 2 mholzer, 1 hansmi, 1 swegener, 1 weeve, 1 eradicator, 1 spider, 1 dholm, 1 tester, Doesn't sound like ulimit to me, but rather the fs.file-max setting available though sysctl. On my server that is set to 50743 by default. I can affirm ulimit -a gives 1024 for max_open_files on this system too. When cherokee is running one hour or so and has served a lot of files lsof | grep cherokee | grep www | wc -l (files are under /var/www) values bigger than 5000 can be reached. I don't have any /proc/fs/file-max... To be honest I don't really care what actually caused the problem (well, I do, but it's not for that readon I opened this bug report). The problem is cherokee in the current configuration can bring a "standard" Gentoo-based server (I did not make too many modifications on the sysctl/limits field, if not none of them next to some IP related settings) on its knees, which is a severe problem (especially if it disables you to log in on your machine) Is this problem still existing in the current versions? please reopen this bug, if it still is a problem to you. AFAICT the problem has been fixed upstream. |
