On Mon, Jun 09, 2008 at 11:37:45AM +0300, Marian Marinov wrote: > On Monday 09 June 2008 10:26:42 Peter Pentchev wrote: > > On Mon, Jun 09, 2008 at 10:11:17AM +0300, Marian Marinov wrote: > > > On Monday 09 June 2008 09:18:06 Danail Petrov wrote: > > > > Marian Marinov wrote: > > > > > Много е вероятно apache-а ти да е бил рестартиран с много нисък лимит > > > > > за opened files. > > > > > > > > > > напиши ulimit -a виж лимита с които си в момента след което > > > > > рестартирай apache-a. > > > > > > > > Това с потребителя на apache обаче трябва да го напишеш. > > > > > > Грешка, трябва да го напише на console-та от която се стартира > > > apache-а(от root). Ако го направи от nobody няма да свърши никаква > > > работа тъй като apache не слага RLIMIT_OFILE. Дефакто ситуацята е > > > следната, ulimit e команда на bash и bash налага лимита за maximum > > > opened files. След като се стартра apache-а от root тези лимити са > > > наложени за процеса баща и всички негови деца ги онаследяват. Съответно > > > ако детето не изпълнява bash за да изпълни скрипт-а или ако не сетва > > > RLIMIT_OFILE то лимитите остават тези с които е бил стартиран от root, > > > което е и най-вероятният проблем. > > > > А всъщност Данаил е прав и това ulimit -a е най-добре да бъде изпълнено > > в CGI скрипт, пуснат точно от този Apache, който прави проблеми :) > > > > Мариане, не можеш твърдо да кажеш, че Apache не слага RLIMIT_OFILE; > > съвсем не можеш да бъдеш сигурен точно кой и как е конфигурирал точно > > този Apache, с който човекът има проблем. Аз на четири машини в един и > > същи мрежови сегмент имам четири инсталации на Apache, конфигурирани по > > съвършено различен начин, и два от тях ги стартирам през допълнителни > > скриптове, които поставят ограничения, които стандартният конфигурационен > > файл на Apache не поставя :) И това съвсем стандартно, през > > /etc/apache2/envvars - HTTPD='/usr/sbin/neshto-si-tam /usr/sbin/apache2' > > > > Да, и при мен никой от уебсървърите няма ограничение за брой отворени > > файлове, но не можеш да си сигурен, че някой друг не е конфигурирал своя > > уебсървър така. > > > > Поздрави, > > Петър > > 1. Сигурен съм че, Apache не слага RLIMIT_OFILE тъй като никъде в кода на > сървъра няма подобно нещо.
Това не е съвсем вярно :) В стандартната конфигурация на Apache няма директива за това ограничение, така е... само че в сорса на Apache 2.2 съвсем даже си има възможност за поддръжка на RLIMIT_NOFILE, ако операционната система го поддържа :) Направи едно търсене за "limit_nofile" и "RLIMIT_NOFILE" в сорсовете... принципно го поддържа, само че никъде не е изведено така, че администраторът да може да го ползва. Объркването ти може би е дошло от това, че *официалното* име на това ограничение е RLIMIT_NOFILE, а не RLIMIT_OFILE :) Но си прав, че на практика системният администратор НЕ може да накара Apache да сложи това ограничение с чиста конфигурация. > 2. Ако сървъра е с mod_php RLIMIT_OFILE се взима от shell-а стартрал apache-а. ...освен ако няма някакви наложени ограничения за потребител "nobody" или "www-data" или към каквото още Apache прави setuid след това. Но това в сорса на Apache май като че ли го няма, така че тук си прав :) Но все пак виж по-долу, защото тук влиза в действие и точка 4 :) > 3. Ако сървъра изпълнява PHP-тата като CGI-ки то тогава трябва да се погледне > лимита който е сложен на всеки новостартиран shell на машната. 99.9% сигурен > съм, че няма отделен лимит само за този потребител на машина и в такъв случай > остават само стандартните лимити наложени в /etc/bashrc, /etc/profile > или /etc/profile.d в зависимост от дистрибуцията. Мдам, така е, само че... > 4. Някои дистрибуции имат в скриптовете за стартиране на apache сложени > лимити и това също може да се провери. А... е ТОЧНО за това говоря! Тук въпросът не е в "някои дистрибуции"; това, за което говорех в предишното съобщение, е, че съвсем *стандартната* конфигурация на Apache, съвсем стандартният начин за стартиране с apachectl, което или администраторът изпълнява на ръка, или бива пуснато от /etc/init.d/apache или каквото там, *дава възможност* на администратора да пипне файла /etc/apache2/envvars (или /usr/local/etc/apache/envvars или където там дистрибуцията го е инсталирала), за да си настрои всякакви неща. И съвсем стандартното apachectl не изпълнява сляпо "httpd", а гледа дали администраторът не е пипнал файла envvars или по някакъв друг начин не е казал да изпълни *друга* команда за истинското стартиране на Apache. И администраторът съвсем спокойно може да пипне envvars специално за неговата си среда, за конкретната инсталация на Apache с конкретните нужди за конкретните потребители, и да сложи нещо като: HTTPD='/usr/sbin/my-ulimit-wrapper /usr/sbin/httpd' ...и в /usr/sbin/my-ulimit-wrapper да забие едно 'ulimit -n 8' :) Да, това би било глупаво; да, това би се отразило много зле на целия Apache... но все пак не можеш да го изключиш като вариант. Да, сега каза, че "това може да се провери", но в предишния ти коментар изобщо не допускаше подобна възможност. Аз просто казвам, че единственият начин човекът да е сигурен *с какви ограничения му се изпълняват PHP скриптовете* е да пусне *PHP скрипт* и от него да види ограниченията :) Просто казвам, че е възможно ulimit от конзолата да пропусне нещо. Та така... а сега май е време за обяд :) Поздрави, Петър -- Peter Pentchev [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 The rest of this sentence is written in Thailand, on
pgpD1naBYNyaT.pgp
Description: PGP signature
_______________________________________________ Lug-bg mailing list [email protected] http://linux-bulgaria.org/mailman/listinfo/lug-bg
