Admins

Le problème se reproduit d'un simple reload/restart d'apache2

Cette VM est bien issue de la migration de mail@pavot ?
Si c'est le cas, dans la migration il y a eu un passage d'apache de la version 2.22 à 2.4, c'est peut être une piste…

benj a modifié le configuration d'apache2 pour ne plus servir les CGI en mode FASTCgi (mais un autre mode plus lent), ça a l'air d'avoir résolu le problème.
Cf :

< benj!~user@home.drieu.org: j'ai passé wws en CGI normal
< benj!~user@home.drieu.org: les perfs sont moins bonnes mais ça permettra d'attendre que je retouche à ça

Peut-on avoir un détail de la modification ?

J'ai juste supprimé le module fcgid et le SetHandler fcdi-script du fichier /etc/apache2/conf-available/sympa.conf

J'ai ajouté l'user www-data au groupe sympa pour lui permettre de killer le process :

usermod -a -G sympa www-data

J'ai restauré le fcgi car on avait de gros problèmes de montée en charge.

Par ailleurs j'ai cour-cuircuité l'accès aux rss de sympa qui peut engendrer pas mal de calcul.

Question pour benj : sympa-soap.conf est il une nécessité ? Ne sachant pas à quoi ça nous sert, je l'ai viré.

Bien sur un logrotate -f /etc/logrotate.d/sympa fait le job. :)

beh non, ya aut'chose...

Trouvé.

D'une part je pensais la fois d'avant avoir réussi car le reload fonctionnait. Mais, trop pressé que j'étais, je n'ai pas reloadé la page web et je n'ai pas laissé à nagios le temps de le faire, du coup le reload et le logrotate ont fonctionné car il n'y avait pas de process fcgi.

Ensuie la source de notre problème est le mpm_event. La solution :

 a2dismod mpm_event && a2enmod mpm_prefork

Pour info : https://serverfault.com/questions/383526/how-do-i-select-which-apache-mpm-to-use
La page qui m'a mise sur la voie (oui, plesk, c'est moche ...) : https://support.plesk.com/hc/en-us/articles/213946305-Apache-crashes-on-reload-and-websites-show-502-Bad-Gateway-seg-fault-or-similar-nasty-error-detected-in-the-parent-process

Par ailleurs une limite de 20 processes fcgid permet de passer un stress test soutenu, avec le cpu à 100% et la RAM à 100% (sans swap).

Le stress test :

# cat ./stress_april.org.sh
while true
do
     curl -s https://listes.april.org/wws/lists>/dev/null &
     curl -s https://listes.april.org/wws/info/accessibilite>/dev/null &
     curl -s https://listes.april.org/wws/subscribe/campagne-adhesion>/dev/null &
     curl -s https://listes.april.org/wws/rss_request/campagne-adhesion>/dev/null &
     curl -s 'https://listes.april.org/wws/rss/latest_arc/sensibilisation?count=2000&for=10000'>/dev/null &
     echo -n .
     sleep .2
done

En CGI, un sleep 2 suffisait à stresser fortement le serveur. D'ou une source supposée des outages récents de sympa.

Malheureusement ça ne fait pas tout. Désormais on a un apache qui stop/stop correctement mais le reload est toujours HS.

On a cette erreur ci : http://blog.kavoori.com/2015-03-21/apache-crash-with-seg-fault.html

Pour contourner temporairement le problème :

--- a/etc/logrotate.d/apache2
+++ b/etc/logrotate.d/apache2
@@ -10,9 +10,11 @@
     create 640 root adm
     sharedscripts
     postrotate
-                if /etc/init.d/apache2 status > /dev/null ; then \
-                    /etc/init.d/apache2 reload > /dev/null; \
-                fi;
+           systemctl stop  apache2.service
+               systemctl start apache2.service
+               #if /etc/init.d/apache2 status > /dev/null ; then \
+               #    /etc/init.d/apache2 reload > /dev/null; \
+               #fi;

Je pense qu'on gagnera notre énergie à d'abord passer la vm en stretch.