Re: [Lug-bg] Too many open files in....

[Peter Pentchev <roam@xxxxxxxxxxx>]

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	roam@xxxxxxxxxxx    roam@xxxxxxxx    roam@xxxxxxxxxxx
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

Attachment: pgpxO0oJF6Xut.pgp
Description: PGP signature

_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg