Forum général.général Apache s'arrête

Posté par  .
Étiquettes : aucune
0
9
juil.
2006
Bonjour,
Depuis quelques temps, apache2 qui tourne sur un vserver (qui ne m'appartient pas) quitte tout seul et je suis obligé de le redémarrer à la main.

J'ai jeté un oeil au fichier error.log, et je remarque quelques trucs bizarres:

[client 67.95.203.244] script '/var/www/htdocs/adxmlrpc.php' not found or unable to stat
[Sat Jul 08 23:19:26 2006] [error] [client 67.95.203.244] File does not exist: /var/www/htdocs/adserver
[Sat Jul 08 23:19:27 2006] [error] [client 67.95.203.244] File does not exist: /var/www/htdocs/phpAdsNew
[Sat Jul 08 23:40:20 2006] [error] [client 171.66.124.101] File does not exist: /var/www/htdocs/main
[Sat Jul 08 23:40:20 2006] [error] [client 171.66.124.101] File does not exist: /var/www/htdocs/cms
[Sat Jul 08 23:40:22 2006] [error] [client 171.66.124.101] File does not exist: /var/www/htdocs/components
[Sun Jul 09 01:51:09 2006] [error] [client 207.46.98.49] File does not exist: /var/www/htdocs/robots.txt


Tentative d'exploitation d'une faille XML-RPC ?

Plus quelques lignes du genre:

[Thu Jul 06 19:09:02 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/sys
[Thu Jul 06 19:09:02 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/fairydkp
[Thu Jul 06 19:09:03 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/rps
[Thu Jul 06 19:09:03 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/mc1
[Thu Jul 06 19:09:04 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/dkpaq
[Thu Jul 06 19:09:04 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/ttmdkp
[Thu Jul 06 19:09:04 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/wowdkp
[Thu Jul 06 19:09:05 2006] [error] [client 65.39.142.79] File does not exist: /var/www/htdocs/dkpold


Par contre là je ne comprends pas trop le but de la manoeuvre...

Enfin, voici le signal d'arrêt d'apache:

[Sun Jul 09 05:15:52 2006] [warn] child process 14197 still did not exit, sending a SIGTERM
[Sun Jul 09 05:15:53 2006] [warn] child process 21612 still did not exit, sending a SIGTERM
[Sun Jul 09 05:15:54 2006] [warn] child process 14197 still did not exit, sending a SIGTERM
[Sun Jul 09 05:15:54 2006] [warn] child process 21612 still did not exit, sending a SIGTERM
[Sun Jul 09 05:15:56 2006] [warn] child process 14197 still did not exit, sending a SIGTERM
[Sun Jul 09 05:15:56 2006] [warn] child process 21612 still did not exit, sending a SIGTERM
[Sun Jul 09 05:15:58 2006] [error] child process 14197 still did not exit, sending a SIGKILL
[Sun Jul 09 05:15:58 2006] [error] child process 21612 still did not exit, sending a SIGKILL
[Sun Jul 09 05:16:01 2006] [notice] caught SIGTERM, shutting down


Est-ce à cause de ces accès répétitifs et brutaux que le serveur s'arrête ?
Peut-on y faire quelque chose, sans changer le port d'apache ?

Merci !

  • # Arrêt machine ?

    Posté par  . Évalué à 1.


    Jul 9 05:09:09 vs162110 /USR/SBIN/CRON[24451]: (root) CMD ( [ -d /var/lib/php4 ] && find /var/lib/php4/ -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm)
    Jul 9 05:18:17 vs162110 syslogd 1.4.1#17: restart.


    Syslogd s'est arrêté juste avant... bizarre non ?
    Pas de restart de la machine à priori, puisque l'uptime est toujours de quelques jours...

    • [^] # Re: Arrêt machine ?

      Posté par  (site web personnel) . Évalué à 3.

      Rien d'etrange dans tout cela. verifie ton script de rotation de log
      il a peut-etre un problème, il ne devrait pas arreter apache ce qu'il
      semble faire.

      Emplacement a verifier sous debian: /etc/logrotate.d/apache2

      /var/log/apache2/*.log {
      weekly
      missingok
      rotate 52
      compress
      delaycompress
      notifempty
      create 640 root adm
      sharedscripts
      postrotate
      if [ -f /var/run/apache2.pid ]; then
      /etc/init.d/apache2 restart > /dev/null
      fi
      endscript
      }

      • [^] # Re: Arrêt machine ?

        Posté par  (site web personnel) . Évalué à 2.

        Mouais j'ai manqué de clareté dans ma phrase moi. Ce voulais dire que les cut&paste d' error.log fourni dans le journal ne sont pas des signes avant-coureur de gros problèmes.

        Notamment dans le dernier bloc il est clair qu'apache a reçu l'ordre de s'arreter, ordre qu'il propage à ses forks.

        Il te reste a trouver qui lui donne cet ordre. Un indice est que cela intervient au meme momment que la rotation des logs de syslog (identifié par le message syslog ... restart).

        Une information importante que tu as oublié de fournir est la periode et la frequence des arrêts d'apache (tout les jours / toutes les semaines / ..)

        Amha il te faut fouiner dans /etc/cron.daily et /etc/logrotate.d (sous debian en tout cas ce sont les premiers dossiers a analyser).

        • [^] # Re: Arrêt machine ?

          Posté par  . Évalué à 1.

          Peut être que c'est le kernel lui même qui a dit à apache de s'arrêter parce qu'il consommait trop de mémoire en acceptant trop de clients simultanément. Il me semble que c'est ce que fait le kernel pour éviter le plantage du système complet, mais je ne sais pas quel signal il envois. Vérifies la valeur de MaxClients.

          • [^] # Re: Arrêt machine ?

            Posté par  (site web personnel) . Évalué à 2.

            Sauf que dans ce cas apache serait mort bcp plus violement, qu'aucun message
            n'aurait été loggé dans l'error.log mais par contre un oom_killer serait apparu dans le dmesg.

        • [^] # Re: Arrêt machine ?

          Posté par  . Évalué à 0.

          Merci de ces indications, je vais examiner encore un peu tout cela !

  • # access.log ou access_log

    Posté par  . Évalué à 3.

    Jettes un oeil du coté du fichier access.log (ou access_log apparement). Tu verras quelles url ont été demandées, et surtout combien.

    Peut être que ça t'en apprendras plus ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.