Re: stabiliaetsprobleme mit apache-2.2.6

[Paul Puschmann <ln...@uzulabs.net>]

On Wed, Oct 31, 2007 at 07:31:17PM +0100, 6bone@6bone.informatik.uni-leipzig.de wrote:
> Hallo,
> 
> ich benutze den apache-2.2.6 mit folgender Konfiguration:
> 
> Server Version: Apache/2.2.6 (Unix) mod_ssl/2.2.6 DAV/2 
> mod_auth_pgsql/2.0.3 PHP/5.2.4
> 
> Betriebssystem netbsd (Multiprozessor)
> 
> Der Apache selbt laeuft stabil. Probleme treten nur beim Logrotate auf. 
> Wird ein SIGHUP an den Apache kommt es in seltenen Faellen vor, dass der 
> Apache nach dem Erhalt des Signales nicht mehr korrekt arbeitet. Teile der 
> apache-config werden jetzt zusammen mit den Webseiten ausgeliefert. Im 
> errorlog findet man einen Eintrag (siehe unten).
> 
> Das Verhalten ist recht suboptimal, da ich jetzt nach jedem logrotate 
> nachsehen muss ob der Apache noch richtig arbeitet.
> 
> Hat jemand eine Idee was man gegen das Verhalten tun kann?
> 
Per Cron einen erneuten Restart nach dem Logrotate durchführen?

Tritt dieser Fehler auch nach einem manuellen Neustart auf oder nur
mit Logrotate? 
Weißt du wie das Logrotate arbeitet? Muss der Apache selbst das
Logfile neu anlegen? Vielleicht hakt es ja hier?

Paul

> ##### Auszug aus dem error_log #####
> 
> [Wed Oct 31 12:00:12 2007] [notice] SIGHUP received.  Attempting to 
> restart
> [Wed Oct 31 12:00:24 2007] [notice] Digest: generating secret for digest 
> authentication ...
> [Wed Oct 31 12:00:24 2007] [notice] Digest: done
> [Wed Oct 31 12:00:24 2007] [notice] Apache/2.2.6 (Unix) mod_ssl/2.2.6 O} eq 
> "Snake Oil, Ltd." \\\n#            and %{SSL_CLIENT_S_DN_OU} in {"Staff", 
> "CA", "Dev"} \\\n#            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 
> \\\n#            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \\\n# 
> or %{REMOTE_ADDR} =~ m/^192\\.76\\.162\\.[0-9]+$/\n#</Location>\n\n#   SSL 
> Engine Options:\n#   Set various options for the SSL engine.\n#   o 
> FakeBasicAuth:\n#     Translate the client X.509 into a Basic 
> Authorisation.  This means that\n#     the standard Auth/DBMAuth methods 
> can be used for access control.  The\n#     user name is the `one line' 
> version of the client's X.509 certificate.\n#     Note that no password is 
> obtained from the user. Every entry in the user\n#     file needs this 
> password: `xxj31ZMTZzkVA'.\n#   o ExportCertData:\n#     This exports two 
> additional environment variables: SSL_CLIENT_CERT and\n#     
> SSL_SERVER_CERT. These contain the PEM-encoded certificates of the\n#     
> server (always existing) and the client (only existing when client\n#     
> authentication is used). This can be used to import the certificates\n#     
> into CGI scripts.\n#   o StdEnvVars:\n#     This exports the standard 
> SSL/TLS related `SSL_*' environment variables.\n#     Per default this 
> exportation is switched off for performance reasons,\n#     because the 
> extraction step is an expensive operation and is usually\n#     useless for 
> serving static content. So one usually enables the\n#     exportation for 
> CGI and SSI requests only.\n#   o StrictRequire:\n#     This denies access 
> when "SSLRequireSSL" or "SSLRequire" applied even\n#     under a "Satisfy 
> any" situation, i.e. when it applies access is denied\n#     and no other 
> module can change it.\n#   o OptRenegotiate:\n#     This enables optimized 
> SSL connection renegotiation handling when SSL\n#     directives are used 
> in per-directory context. \n#SSLOptions +FakeBasicAuth +ExportCertData 
> +StrictRequire\n<FilesMatch "\\.(cgi|shtml|phtml|php)$">\n    SSLOptions 
> +StdEnvVars\n</FilesMatch>\n<Directory "/usr/pkg/libexec/cgi-bin">\n    
> SSLOption\x84\xc0\x06\bT\xc0\x06\bH\xc0\x06\b\xd03\x1a\b0\xe0\x1f\b\xe9 
> DAV/2 mod_auth_pgsql/2.0.3 PHP/5.2.4 configured -- resuming normal 
> operations


-- 
: Bitte einen Realname benutzen, unter dem Zitat antworten
: und einfache Text-Mails senden (kein HTML).
: Danke.

Re: stabiliaetsprobleme mit apache-2.2.6

[6b...@6bone.informatik.uni-leipzig.de]

Hallo,

Bei einem manuellen Neustart treten keine Probleme auf. Wobei ein Neustart 
aber ein stop und start beinhaltet und nicht wirklich mit einem Signal zu 
vergleichen ist.

Meines Wissens erstellt das logrotate das logfile neu. Das sollte also 
kein Problem sein.

Uwe

On Thu, 1 Nov 2007, Paul Puschmann wrote:
> Per Cron einen erneuten Restart nach dem Logrotate durchf�hren?
>
> Tritt dieser Fehler auch nach einem manuellen Neustart auf oder nur
> mit Logrotate?
> Wei�t du wie das Logrotate arbeitet? Muss der Apache selbst das
> Logfile neu anlegen? Vielleicht hakt es ja hier?
>
> Paul
>