when in the /etc/conf.d/apache2 -D PERl is set, a /etc/init.d/apache2 stop ends with error: # /etc/init.d/apache2 stop * Stopping apache2 ... [ !! ] * ERROR: apache2 failed to stop BUT, the apache is stopped and no instance is left. This behaviour ist not when '-D PERL' is not set. Also an perl-cleaner --reallyall dont solved this. any ideas? emerge --info: Portage 2.2.8-r1 (default/linux/amd64/13.0, gcc-4.7.3, glibc-2.17, 3.10.32_weber3.10.32 x86_64) ================================================================= System uname: Linux-3.10.32_weber3.10.32-x86_64-Intel-R-_Core-TM-_i7-4770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 32767632 total, 30804348 free KiB Swap: 0 total, 0 free Timestamp of tree: Sun, 09 Mar 2014 12:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r3, 3.3.3 dev-util/cmake: 2.8.11.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.11.6, 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3-r1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -mtune=generic -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=core2 -mtune=generic -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,--as-needed" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" USE="acl amd64 berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 mmx modules multilib ncurses nls nptl openmp pam pcre readline session sse sse2 ssl tcpd unicode zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="actions alias autoindex auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user cache cgi deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif status unique_id vhost_alias" APACHE2_MPMS="prefork" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON Reproducible: Always
IRC, there should be a log of this failed run in /var/log/apache2/...
Please attach the /etc/conf.d/apache2 file that gives you this problem.
(In reply to Rafał Mużyło from comment #1) > IRC, there should be a log of this failed run in /var/log/apache2/... there happens NOTHING in /var/log/apache2/*.log sorry that
(In reply to Jeroen Roovers from comment #2) > Please attach the /etc/conf.d/apache2 file that gives you this problem. # /etc/conf.d/apache2: config file for /etc/init.d/apache2 # When you install a module it is easy to activate or deactivate the modules # and other features of apache using the APACHE2_OPTS line. Every module should # install a configuration in /etc/apache2/modules.d. In that file will have an # <IfDefine NNN> directive where NNN is the option to enable that module. # # Here are the options available in the default configuration: # # AUTH_DIGEST Enables mod_auth_digest # AUTHNZ_LDAP Enables authentication through mod_ldap (available if USE=ldap) # CACHE Enables mod_cache # DAV Enables mod_dav # ERRORDOCS Enables default error documents for many languages. # INFO Enables mod_info, a useful module for debugging # LANGUAGE Enables content-negotiation based on language and charset. # LDAP Enables mod_ldap (available if USE=ldap) # MANUAL Enables /manual/ to be the apache manual (available if USE=docs) # MEM_CACHE Enables default configuration mod_mem_cache # PROXY Enables mod_proxy # SSL Enables SSL (available if USE=ssl) # STATUS Enabled mod_status, a useful module for statistics # SUEXEC Enables running CGI scripts (in USERDIR) through suexec. # USERDIR Enables /~username mapping to /home/username/public_html # # # The following two options provide the default virtual host for the HTTP and # HTTPS protocol. YOU NEED TO ENABLE AT LEAST ONE OF THEM, otherwise apache # will not listen for incomming connections on the approriate port. # # DEFAULT_VHOST Enables name-based virtual hosts, with the default # virtual host being in /var/www/localhost/htdocs # SSL_DEFAULT_VHOST Enables default vhost for SSL (you should enable this # when you enable SSL) # ## mychange start APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE -D PHP5 -D PERL -D CACHE -D STATUS -D MEM_CACHE -D FASTCGI -D FASTCGI_HANDLER" ## mychange stop # Extended options for advanced uses of Apache ONLY # You don't need to edit these unless you are doing crazy Apache stuff # As not having them set correctly, or feeding in an incorrect configuration # via them will result in Apache failing to start # YOU HAVE BEEN WARNED. # PID file #PIDFILE=/var/run/apache2.pid # timeout for startup/shutdown checks #TIMEOUT=10 # ServerRoot setting #SERVERROOT=/usr/lib64/apache2 # Configuration file location # - If this does NOT start with a '/', then it is treated relative to # $SERVERROOT by Apache #CONFIGFILE=/etc/apache2/httpd.conf # Location to log startup errors to # They are normally dumped to your terminal. #STARTUPERRORLOG="/var/log/apache2/startuperror.log" # A command that outputs a formatted text version of the HTML at the URL # of the command line. Designed for lynx, however other programs may work. #LYNX="lynx -dump" # The URL to your server's mod_status status page. # Required for status and fullstatus #STATUSURL="http://localhost/server-status" # Method to use when reloading the server # Valid options are 'restart' and 'graceful' # See http://httpd.apache.org/docs/2.2/stopping.html for information on # what they do and how they differ. #RELOAD_TYPE="graceful"
...so it seems the next step would be uncommenting STARTUPERRORLOG and checking what gets printed there.
(In reply to Rafał Mużyło from comment #5) > ...so it seems the next step would be uncommenting STARTUPERRORLOG and > checking what gets printed there. webserver-zbf apache2 # /etc/init.d/apache2 stop * Caching service dependencies ... [ ok ] * Stopping apache2 ... [ !! ] * ERROR: apache2 failed to stop webserver-zbf apache2 # /etc/init.d/apache2 zap * Manually resetting apache2 to stopped state webserver-zbf apache2 # /etc/init.d/apache2 start * Starting apache2 ... [ ok ] webserver-zbf apache2 # /etc/init.d/apache2 restart * Stopping apache2 ... [ !! ] * ERROR: apache2 failed to stop webserver-zbf apache2 # /etc/init.d/apache2 stop * Stopping apache2 ... [ !! ] * ERROR: apache2 failed to stop webserver-zbf apache2 # /etc/init.d/apache2 zap * Manually resetting apache2 to stopped state webserver-zbf apache2 # /etc/init.d/apache2 start * Starting apache2 ... webserver-zbf apache2 # cat /var/log/apache2/startuperror.log Syntax OK Syntax OK Syntax OK thats all what is listed in the logfile ;-(
i also find this in /var/log/apache2/error_log [Wed Mar 12 16:45:36 2014] [notice] Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.1f mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.7 Perl/v5.16.3 configured -- resuming normal operations [Wed Mar 12 16:45:41 2014] [warn] child process 13465 still did not exit, sending a SIGTERM [Wed Mar 12 16:45:43 2014] [warn] child process 13465 still did not exit, sending a SIGTERM [Wed Mar 12 16:45:45 2014] [warn] child process 13465 still did not exit, sending a SIGTERM [Wed Mar 12 16:45:47 2014] [error] child process 13465 still did not exit, sending a SIGKILL [Wed Mar 12 16:45:48 2014] [notice] caught SIGTERM, shutting down [Wed Mar 12 16:45:51 2014] [notice] FastCGI: process manager initialized (pid 13504) [Wed Mar 12 16:45:51 2014] [notice] Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.1f mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.7 Perl/v5.16.3 configured -- resuming normal operations
ok. any news on this bug?
I currently have no working setup using mod_perl. So I cannot promise to provide a fix soon. On the other hand patches are welcome.
OK same story here... I kinda narrowed the issue down to where the initscript checks whether the pidfile is still there in stop(). For whatever reason, it seems that the pidfile will exist for the tiniest amount of time after the actual process identified in it has terminated. So I have added a second while loop immediately after that to wait for the pidfile to disappear. If this doesn't happen within the prescribed timeout, stopping will fail, but so far I haven't seen more than approximately one second of delay. Not necessarily the prettiest thing but it gets the job done. I suppose I have replaced the first && with || in the condition of the original while loop... I'm not 100% sure I'm not missing something here. Any thoughts? local i=0 retval=0 while ( test -f "${PIDFILE}" && pgrep -P ${PID} apache2 >/dev/null ) \ && [ $i -lt ${TIMEOUT} ]; do sleep 1 && i=$(expr $i + 1) done + local i=0 + while [ -f "${PIDFILE}" ] && [ $i -lt ${TIMEOUT} ]; do + sleep 1 && i=$(expr $i + 1) + done + [ -e "${PIDFILE}" ] && retval=1
Same issue here on i686 target.
The suggested solution posted in the following thread seems to resolve this issue and has worked for me (with apache-2.2.27, perl-5.16.3, and mod_perl-2.0.7 installed): https://forums.gentoo.org/viewtopic-t-927794-start-0.html ... I'm sure you guys can probably find a much cleaner way to work the necessary fixes into the necessary ebuilds though :-). I went ahead and actually re-built apache2, perl, and mod_perl (even though the thread only mentioned perl and mod_perl) just to be sure. The only minor problem that I have now is that, when issuing a restart or stop command, the init script for apache now claims that it is failing to stop (even though the apache process has actually ended) and will need to be "zapped" back into a stopped state. After that, apache starts just fine. The reload command on the other hand works just fine. Initially, I thought maybe that building apache with the "threads" USE flag selected (since the perl was built with "ithreads" USE flag selected) and then rebuilding perl and mod_perl accordingly might solve this, but that isn't a potential solution in my case as the php ebuild required the "threads" USE flag to be *unselected*.
Created attachment 375730 [details, diff] apache2.initd.patch If it's really only the pidfile which stays a bit longer than the apache process the attached patch might fix it. Can you please patch your /etc/init.d/apache2 file with the attached file and report back if that fixes your issues?
What I did was basically this: - while ( test -f "${PIDFILE}" && pgrep -P ${PID} apache2 >/dev/null ) \ + while ( test -f "${PIDFILE}" || pgrep -P ${PID} apache2 >/dev/null ) \ ${PID} is retrieved from the pidfile before. So I want to stay in the loop while the process still exists _or_ while the pidfile does. This approach did solve my problem, the initscript returns properly now and a quick verification after that shows no apache2 processes or the pidfile. The bug title is "www-servers/apache init.d start / stop dont work anymore when -D PERL is active," which suggests start doesn't work either. This has not been my experience. Start worked fine at rc, but once you tried to stop apache2 (and it failed) you had to zap it in order for start to work. This is normal behavior, the only reason why start wouldn't work was because stop didn't. Stejarel
(In reply to Stejarel Veres from comment #14) > What I did was basically this: > > - while ( test -f "${PIDFILE}" && pgrep -P ${PID} apache2 >/dev/null ) \ > + while ( test -f "${PIDFILE}" || pgrep -P ${PID} apache2 >/dev/null ) \ > > ${PID} is retrieved from the pidfile before. So I want to stay in the loop > while the process still exists _or_ while the pidfile does. > > This approach did solve my problem, the initscript returns properly now and > a quick verification after that shows no apache2 processes or the pidfile. > > The bug title is "www-servers/apache init.d start / stop dont work anymore > when -D PERL is active," which suggests start doesn't work either. This has > not been my experience. Start worked fine at rc, but once you tried to stop > apache2 (and it failed) you had to zap it in order for start to work. This > is normal behavior, the only reason why start wouldn't work was because stop > didn't. > > Stejarel Hi, yeah sounds logic ......... but when i remove '-D PERL' i had no problems.. marko ps, did not test yet with 2.2.27
(In reply to Marko Weber Bürgermeister from comment #15) > (In reply to Stejarel Veres from comment #14) > > What I did was basically this: > > > > - while ( test -f "${PIDFILE}" && pgrep -P ${PID} apache2 >/dev/null ) \ > > + while ( test -f "${PIDFILE}" || pgrep -P ${PID} apache2 >/dev/null ) \ > > > > ${PID} is retrieved from the pidfile before. So I want to stay in the loop > > while the process still exists _or_ while the pidfile does. > > > > This approach did solve my problem, the initscript returns properly now and > > a quick verification after that shows no apache2 processes or the pidfile. > > > > The bug title is "www-servers/apache init.d start / stop dont work anymore > > when -D PERL is active," which suggests start doesn't work either. This has > > not been my experience. Start worked fine at rc, but once you tried to stop > > apache2 (and it failed) you had to zap it in order for start to work. This > > is normal behavior, the only reason why start wouldn't work was because stop > > didn't. > > > > Stejarel > > Hi, > yeah sounds logic ......... > but when i remove '-D PERL' i had no problems.. > > marko > > ps, did not test yet with 2.2.27 I didn't test without -DPERL. I do need -DPERL. I'm not really sure why the pidfile lingers around for a while after the process has died with -DPERL but not without it. In any case, my take is that this change to the initscript shouldn't hurt either way. Stejarel
(In reply to Stejarel Veres from comment #16) > (In reply to Marko Weber Bürgermeister from comment #15) > > (In reply to Stejarel Veres from comment #14) > > > What I did was basically this: > > > > > > - while ( test -f "${PIDFILE}" && pgrep -P ${PID} apache2 >/dev/null ) \ > > > + while ( test -f "${PIDFILE}" || pgrep -P ${PID} apache2 >/dev/null ) \ > > > > > > ${PID} is retrieved from the pidfile before. So I want to stay in the loop > > > while the process still exists _or_ while the pidfile does. > > > > > > This approach did solve my problem, the initscript returns properly now and > > > a quick verification after that shows no apache2 processes or the pidfile. > > > > > > The bug title is "www-servers/apache init.d start / stop dont work anymore > > > when -D PERL is active," which suggests start doesn't work either. This has > > > not been my experience. Start worked fine at rc, but once you tried to stop > > > apache2 (and it failed) you had to zap it in order for start to work. This > > > is normal behavior, the only reason why start wouldn't work was because stop > > > didn't. > > > > > > Stejarel > > > > Hi, > > yeah sounds logic ......... > > but when i remove '-D PERL' i had no problems.. > > > > marko > > > > ps, did not test yet with 2.2.27 > > I didn't test without -DPERL. I do need -DPERL. I'm not really sure why the > pidfile lingers around for a while after the process has died with -DPERL > but not without it. In any case, my take is that this change to the > initscript shouldn't hurt either way. > > Stejarel just to be sure: > > - while ( test -f "${PIDFILE}" && pgrep -P ${PID} apache2 >/dev/null ) \ > > + while ( test -f "${PIDFILE}" || pgrep -P ${PID} apache2 >/dev/null ) \ this lines are in the /etc/init.d/apache2 ??
The first one is, I replaced && with || in that line to solve the behavior I observed. YMMV.
Thanks for the feedback. http://git.overlays.gentoo.org/gitweb/?p=proj/apache.git;a=commitdiff;h=75da24d75d5fd2f10fc0c3dcfda5beb6c948fda1 This will be in the next gentoo-apache tarball rollout. Please keep this bug open until a fixed apache is in portage.
(In reply to Lars Wendler (Polynomial-C) from comment #19) > Thanks for the feedback. > > http://git.overlays.gentoo.org/gitweb/?p=proj/apache.git;a=commitdiff; > h=75da24d75d5fd2f10fc0c3dcfda5beb6c948fda1 > > This will be in the next gentoo-apache tarball rollout. Please keep this bug > open until a fixed apache is in portage. seems it is not in the new www-servers/apache-2.2.27 , right ?
(In reply to Marko Weber Bürgermeister from comment #20) > (In reply to Lars Wendler (Polynomial-C) from comment #19) > > Thanks for the feedback. > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/apache.git;a=commitdiff; > > h=75da24d75d5fd2f10fc0c3dcfda5beb6c948fda1 > > > > This will be in the next gentoo-apache tarball rollout. Please keep this bug > > open until a fixed apache is in portage. > > seems it is not in the new www-servers/apache-2.2.27 , right ? He stated pretty clearly that this fix was going to be in the next tarball rollout. He didn't say anything about it having gone into the portage tree (other than to keep the bug open until this fix has made it's way into portage). In fact if you read my comment #12 you'll plainly see that I'm on apache-2.2.27 and was effected by the same problem. Seeing as, to date, there isn't any revision level to the package beyond the base level then, yes, this fix is not in the www-servers/apache-2.2.27 package at this moment.
This was fixed in =www-servers/apache-2.2.27-r3 and =www-servers/apache-2.4.9-r3
(In reply to Lars Wendler (Polynomial-C) from comment #22) > This was fixed in =www-servers/apache-2.2.27-r3 and > =www-servers/apache-2.4.9-r3 Any idea as to how long until this revision-level package is stabilized in Portage? I know it's only a revision level defference, but I make it a practice not to install arch-masked packages unless it's absolutely necessary (which isn't immediately necessary given the work-around I'd found).
(In reply to Matthew Dirks from comment #23) > (In reply to Lars Wendler (Polynomial-C) from comment #22) > > This was fixed in =www-servers/apache-2.2.27-r3 and > > =www-servers/apache-2.4.9-r3 > > Any idea as to how long until this revision-level package is stabilized in > Portage? I know it's only a revision level defference, but I make it a > practice not to install arch-masked packages unless it's absolutely > necessary (which isn't immediately necessary given the work-around I'd > found). This is hard to tell. The changes I did in apache-2.2.27-r2 and -r3 must first settle a bit in ~arch. Then there's the usual delay when it comes to stabilization because we're hopelessly understaffed in the team doing stabilizations.
(In reply to Lars Wendler (Polynomial-C) from comment #24) > (In reply to Matthew Dirks from comment #23) > > (In reply to Lars Wendler (Polynomial-C) from comment #22) > > > This was fixed in =www-servers/apache-2.2.27-r3 and > > > =www-servers/apache-2.4.9-r3 > > > > Any idea as to how long until this revision-level package is stabilized in > > Portage? I know it's only a revision level defference, but I make it a > > practice not to install arch-masked packages unless it's absolutely > > necessary (which isn't immediately necessary given the work-around I'd > > found). > > This is hard to tell. The changes I did in apache-2.2.27-r2 and -r3 must > first settle a bit in ~arch. Then there's the usual delay when it comes to > stabilization because we're hopelessly understaffed in the team doing > stabilizations. What is entailed in stabilization process exactly (esp. x86 or amd64)? I mean, if it's just running tests on systems of a certain specification. then maybe random volunteers could help lighten the load on the dedicated teams. I know I wouldn't mind personally chipping in some resources towards those ends from time to time. I know I can't be the only one that makes it a general practice to stick primarily to stabilized packages.
