Хорошо бы ещё твои конкретные соображения по исправлению, раз уж тебя поймало.

Пока нашлось:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200208.mbox/%3CH00000be005f208e.1029264174.river.fscinternet.com@MHS%3E

Конец Треда (ТМ)

Я собрал апач с -D_FILE_OFFSET_BITS=64, две недели полёт нормальный.

А ещё была ситуация, когда access_log разросся до двух гиг за три-четыре дня и
это нормальная ситуация.  Пришлось ротейтить daily...

P.S. А ещё -DHARD_SERVER_LIMIT=1024 сделал.

Что из этого порекомендуешь в Sisyphus? (почти автоматически -- и в backports)

Раорн, а Раорн.  Спек брось, бо что-то у меня:

+ pushd /usr/src/tmp/apache-buildroot/usr/lib/apache
~/tmp/apache-buildroot/usr/lib/apache
~/RPM/BUILD/apache-1.3.34rusPL30.22-alt5/mod_perl-1.29
+ ldd -r libhttpd.so
error: Bad exit status from /usr/src/tmp/rpm-tmp.40741 (%install)

с моим вариантом...

(In reply to comment #3)
> Что из этого порекомендуешь в Sisyphus? (почти автоматически -- и в backports)

Да вот даже не знаю...  С одной стороны падения по SIGXFSZ трудно
диагностируются, с другой - двухгиговый error_log это уже повод задуматься...

HARD_SERVER_LIMIT имеет смысл включать, потому как вниз он зажимается через
MaxClients, а вверх - только пересборкой что не всегда удобно.

(In reply to comment #4)
> Раорн, а Раорн.  Спек брось, бо что-то у меня:

Er...  У меня очень специализированая сборка.  Статикой, только с mod_rewrite,
mod_proxy и log_*, а mod_perl не собирал вообще.  Флаги добавлял в OPTIM.

1.3.34rusPL30.22-alt5:

# you can build --with/--without:
# - M22 or Sisyphus [auto]
# - mod_deflate [with]
# - acl_support [without]
# - largefile_support [with]
# - hardlimit1024 [without]

По части последнего -- Миша/Витя, можете подвесить патч для ручки вместо
тумблера, чтоб число задавалось -- я сейчас притормаживаю.

[Fri Apr 21 17:11:09 2006] [notice] child pid 13604 exit signal Segmentation fault (11)

Лёш, дай спек pls.  Я, наверное, тупой...

Нароод! (raorn)
Бросьте своих спеков или идеально -- патчей к моих спеков :)
Допинаем 1.3.36 до победного.

(In reply to comment #10)
> Бросьте своих спеков или идеально -- патчей к моих спеков :)

Ещё раз - у меня очень спецательная сборка apache.  Статикой, включены _только_
mod_rewrite и mod_proxy.  Всё остальное (включая mod_perl) выкинуто напрочь.  Ну
и экспериментальным методом починил фигню с gdbm.

Если поможет - сейчас приаттачу.

Created attachment 1525 [details]
apache-httpgw.spec

Статика.  Включены _только_ log_agent, log_config, log_referer, proxy и
rewrite.  HARD_SERVER_LIMIT=1024, _FILE_OFFSET_BITS=64.  Починено использование
gdbm в mod_rewrite.

Специализированая сборка для одной задачи - reverse proxy для N хостов с
хитрыми rewrite'ами.

(In reply to comment #12)
> HARD_SERVER_LIMIT=1024, _FILE_OFFSET_BITS=64.
Гы, а я-то apache-1.3.33-alt-hardlimit.patch держал :]  Омакрено.
Проверил, работает.

> Починено использование gdbm в mod_rewrite.
Затянул (пришлось ещё -I%_includedir/db4, заодно оказалось, что libdb1-devel уже
можно выкинуть).

http://old.linux.kiev.ua/~mike/RPM/SRPMS/apache-1.3.37rusPL30.22-alt6.src.rpm

Проверь по возможности, а то уже глаза sleep()аются, да и не готовил я
mod_rewrite с gdbm до сих пор.

сегфолтается с php :( [или это к тому, что уехало ABI и надо пересобрать все
модули, если вливать такого апача?]

[pid 17837] stat64("/var/www/html", {st_mode=S_IFDIR|S_ISGID|0775, st_size=1312,
...}) = 0
[pid 17837] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 17837] chdir("/etc/httpd")         = 0
[pid 17837] rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 17837] kill(17837, SIGSEGV)        = 0
[pid 17837] sigreturn()                 = ? (mask now [])
[pid 17837] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

http://www.redhat.com/archives/fedora-list/2004-November/msg07550.html -- также
нашлось:

# Apache 1.3.37

    * Older versions of Apache 1.3.x had in the file
src/include/ap_config_auto.h a flag:
      #define _LARGEFILE_SOURCE 0
      that you could change to:
      #define _LARGEFILE_SOURCE 1
      Newer versions have a changed source tree, and I don't know how to fix this!
    * Therefore, the old way of forcing (in extremis) ./configure
CFLAGS="-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" will not work with the
current Apache 1.3.37!
    * NOTE: In the past, various distros like Debian, Mandrake or SuSE used to
add unofficial patches to Apache 1.3 to support files >2 GB.

В общем, на основании apache bugs #17453, #36417 придётся закопать как WONTFIX
-- похоже, апстриме задля продвижения горбатого 2.0 добили возможность включить
LFS в 1.3 :-(

Жень, если ещё есть желание -- можешь попробовать проверить, только обязательно
проверь с apache-mod_php.  Непересобранное [с -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE=1?] явно не ожидает такой подставы и сегфолтит деток.

Мне уже не актуально, а на будущее я буду помнить что у нас ограницение лога в 2Г :)

Hacked up versions of 1.3 can serve >2Gb files, some people use that. 
If you build 2.0 with special compiler flags (-DFILE_OFFSET_BITS=64)
that works too, modulo a few bugs - we can't do that in Fedora since it
breaks the binary module interface.

Поэтому raorn@ свой спек выложил, если тебя угораздило нуждаться именно в апаче,
но с такими логами -- собери себе его вариант.  nginx большую статику показывает
и отдаёт на ура; думаю, и с большими логами не должно быть проблем.

PS: в итоге эксперимента, спек от которого сейчас приложу -- оно таки работает,
но после пересборки (без изменений) также php и apache-mod_php (начинаем с
rpm-build-php) или, видимо, других требуемых модулей.  Выкатывать такое
изменение в стабильной ветке всё-таки неосмысленно; если кому когда всё-таки
понадобится и apache-2.2 до той поры себя успеет плохо проявить по части
безопасности, то потребуется синхронизировать пересборку всех модулей apache в
сизифе.

Created attachment 1663 [details]
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE

WARNING: apache built with this spec is BINARY INCOMPATIBLE with non-LFS module
builds!  you will have to rebuild mod_* against it