mod_perl fails in different ways silently fails apache, or causes segmentation fault if the /etc/env.d/02locale is filled with LANG="tr_TR.UTF-8" LC_MESSAGES="tr_TR.UTF-8" LANGUAGE="tr_TR.UTF-8" GDM_LANG="tr_US.TR-8" LC_ALL="tr_TR.UTF-8" SYSFONT="latarcyrheb-sun16" if it is filled with en_US.UTF-8 there seems to be no problem, at least apache starts normally. I need mod_perl for ocsinventory-ng Best Regards Reproducible: Always Steps to Reproduce: 1. Fill 02locale with tr_TR.UTF-8 2. restart system 3. mod_perl fails if you fail to set env variables, mod_perl will start normally, sometimes system does not respect 02locale settings, so several restarts might be useful
tr locale is known to broke applications but still apache should not crash. Could you try to get backtrace? http://www.gentoo.org/proj/en/qa/backtraces.xml
Sorry I do not know how to create a backtrace. I have recompiled apache with debug use falg but I did not able generate a file. Actually I do not have much time. At the moment I am trying to create a new server, hence mod_perl is too broken to be fixed. I have tried the workaround in sabayon based distro and it worked. I have to rebuild whole system and move all data to the newly installed one. (I played too much with mod_perl, dependencies, apache, etc and tried different use flags etc. but now I have a broken system, reconcilio --no-exact and perl-cleaner reallyall does not help)
(In reply to comment #2) > I have tried the workaround in sabayon based distro and it worked. BWT, what workaround are you talking about? In short, to get backtrace you need to rebuild package without -fomit-frame-pointer and with -ggdb in CFLAGS and with splitdebug in FEATURES. After that run ulimit -c unlimited start apache from that shell. Once it crashes, somewhere (in /var/log/apache, pwd or at htdocs) core file may appear. After that to get backtrace all you need is to run gdb --core=corefile /usr/sbin/apache2, or something like that. I don't know specifics of your setup to tell more exact steps. That said, this really will take some time and if time matters it's better to return to this problem later.
Does this issue still exist with 2.0.5?
