Sim refresh error

[crb-admin]

L’opération “sim refresh” ne fonctionne plus sur l’un de nos SIM. Il semblerait que le format du fichier /etc/php-fpm.d/www.conf ne convienne pas à php-fpm…

[simplicite@Test-sim ~]$ sim refresh
…
Job for php-fpm.service failed because the control process exited with error code. See “systemctl status php-fpm.service” and “journalctl -xe” for details.
Done

[simplicite@Test-sim ~]$ systemctl status php-fpm.service
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since lun. 2019-01-21 16:28:21 CET; 1min 28s ago
Process: 6154 ExecStart=/usr/sbin/php-fpm --nodaemonize (code=exited, status=78)
Main PID: 6154 (code=exited, status=78)

[simplicite@Test-sim ~]$ php-fpm
[21-Jan-2019 16:24:38] ERROR: [/etc/php-fpm.d/www.conf:1] Array are not allowed in the global section
[21-Jan-2019 16:24:38] ERROR: Unable to include /etc/php-fpm.d/www.conf from /etc/php-fpm.conf at line 1
[21-Jan-2019 16:24:38] ERROR: failed to load configuration file ‘/etc/php-fpm.conf’
[21-Jan-2019 16:24:38] ERROR: FPM initialization failed

[simplicite@Test-sim ~]$ more /etc/php-fpm.d/www.conf
env[APPS_VERSION] = “5.24”
env[APPS_HOME] = “/var/simplicite”
env[APPS_DATABASES] = “hsqldb,mysql,postgresql”
env[APPS_DEFAULTDATABASE] = “hsqldb”
env[APPS_DEFAULTPROTECTED] = “no”
env[APPS_DEFAULTAUTOSAVE] = “no”
env[APPS_DEFAULTAUTOUPDATE] = “no”
env[APPS_DEFAULTVERSION] = “4.0”
env[APPS_BASEURL] = “test-sim.cr-bretagne.fr”
env[APPS_USERNAME] = “simplicite”
env[APPS_PASSWORD] = “simplicite”
env[APPS_REALMNAME] = “Simplicite Instances Manager”
env[APPS_SSL] = “false”
env[APPS_ALLOWREGISTER] = “no”
env[APPS_ALLOWDOWNLOAD] = “yes”
env[APPS_MAXINSTANCES] = “0”
env[APPS_MAILSERVER] = “smtp.gmail.com”
env[APPS_MAILPORT] = “465”
env[APPS_MAILUSER] = “user@gmail.com”
env[APPS_MAILPASSWORD] = “password”
env[APPS_MAILFROM] = “contact@simplicite.fr”
env[APPS_CLIENT_CA_PATH] = “/C=FR/ST=France/O=Simplicite Software/”
env[APPS_ROOTCONTEXT] = “false”

[simplicite@Test-sim ~]$ php -v
PHP 5.4.16 (cli) (built: Nov 6 2016 00:29:02)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

[simplicite@Test-sim ~]$ php-fpm -v
PHP 5.4.16 (fpm-fcgi) (built: Nov 6 2016 00:30:57)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

[david (David AZOULAY)]

Par hasard est-ce qu’il n’y aurait pas un file system full sur ta VM ?

[crb-admin]

Oui c’était le cas, mais c’est corrigé depuis :

[root@Test-sim ~]# df -k
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/mapper/GROUPVOL-LOGVOL0 27719780 6670804 19828028 26% /
devtmpfs 3994572 0 3994572 0% /dev
tmpfs 4005384 0 4005384 0% /dev/shm
tmpfs 4005384 9544 3995840 1% /run
tmpfs 4005384 0 4005384 0% /sys/fs/cgroup
/dev/mapper/GROUPVOL-LOGVOL2 10190100 2000024 7649404 21% /usr
/dev/sda1 999320 157656 772852 17% /boot
/dev/mapper/GROUPVOL-LOGVOL1 10190100 2900336 6749092 31% /var
/dev/mapper/GROUPVOL-LOGVOL3 10190100 7039036 2610392 73% /var/backup
tmpfs 801080 0 801080 0% /run/user/1020
tmpfs 801080 0 801080 0% /run/user/1014
tmpfs 801080 0 801080 0% /run/user/1017
tmpfs 801080 0 801080 0% /run/user/1018
tmpfs 801080 0 801080 0% /run/user/1016
tmpfs 801080 0 801080 0% /run/user/1005
tmpfs 801080 0 801080 0% /run/user/1022
tmpfs 801080 0 801080 0% /run/user/1015
tmpfs 801080 0 801080 0% /run/user/1002
tmpfs 801080 0 801080 0% /run/user/1023
tmpfs 801080 0 801080 0% /run/user/1012
tmpfs 801080 0 801080 0% /run/user/1021
tmpfs 801080 0 801080 0% /run/user/1010
tmpfs 801080 0 801080 0% /run/user/1008
tmpfs 801080 0 801080 0% /run/user/0
[root@Test-sim ~]#

[crb-admin]

Est-ce qu’il y a un truc à faire une fois le pb d’espace disque corrigé pour tout remettre d’équerre?

[guithel (Guillaume Thelohan CRB)]

Bonjour, nous avons encore ce problème. Avez-vous une idée de l’origine du problème ?

Merci,

Guillaume

[david (David AZOULAY)]

L’origine du pb c’est votre file system full

Pour réparer les conséquences du pb, il faut recréer le /etc/php-fpm.d/www.conf avec son contenu d’origine et de refaire un sim refresh

[guithel (Guillaume Thelohan CRB)]

C’est bon, tout refonctionne. Merci !

[david (David AZOULAY)]

Ok super.

J’ai régardé, au niveau du SIM on ne peut pas facilement et de manière fiable (dans le cas général) anticiper le file system full, donc c’est à checker en amont du SIM.

Pensez donc à faire un check régulier, vider les sauvegardes, etc. pour éviter le file system full

[crb-admin]

Le problème vient de se reproduire sur une autre machine : rec-sim : suite à un disque plein, nginx ne fonctionnait plus.

J’ai donc copié/collé le fichier /etc/php-fpm.d/www.conf depuis une autre machine pour refaire marcher le SIM.

Cependant cette procédure ne me satisfait pas : comment expliquer que le fichier www.conf soit écrasé? N’est-il pas possible de l’éviter ?

[david (David AZOULAY)]

Ca s’explique par le fait qu’il est créé par le sim refresh, s’il n’y a plus de place sur disque il ne peut donc pas être créé (ou plutôt il est bien créé mais vide).

Mais bon s’il n’y a plus de place sur disque il peut y avoir plein d’autre pbs incompréhensibles (un git checkout partiels etc.)

Bref il faut éviter de se retrouver dans ce cas.

[crb-admin]

le fichier est bien créé mais pas avec le bon contenu, il manque des bouts par rapport à ce qu’on trouve sur d’autres SIM :

[root@Rec-sim php-fpm.d]# more www.conf
env[APPS_VERSION] = “5.25”
env[APPS_HOME] = “/var/simplicite”
env[APPS_DATABASES] = “hsqldb,mysql,postgresql”
env[APPS_DEFAULTDATABASE] = “hsqldb”
env[APPS_DEFAULTPROTECTED] = “no”
env[APPS_DEFAULTAUTOSAVE] = “no”
env[APPS_DEFAULTAUTOUPDATE] = “no”
env[APPS_DEFAULTVERSION] = “4.0”
env[APPS_BASEURL] = “rec-sim.cr-bretagne.fr”
env[APPS_USERNAME] = “simplicite”
env[APPS_PASSWORD] = “simplicite”
env[APPS_REALMNAME] = “Simplicite Instances Manager”
env[APPS_SSL] = “false”
env[APPS_ALLOWREGISTER] = “no”
env[APPS_ALLOWDOWNLOAD] = “yes”
env[APPS_MAXINSTANCES] = “0”
env[APPS_MAILSERVER] = “smtp.gmail.com”
env[APPS_MAILPORT] = “465”
env[APPS_MAILUSER] = "user@gmail.com"
env[APPS_MAILPASSWORD] = “password”
env[APPS_MAILFROM] = "contact@simplicite.fr"
env[APPS_CLIENT_CA_PATH] = “/C=FR/ST=France/O=Simplicite Software/”
env[APPS_ROOTCONTEXT] = “false”

[crb-admin]

Malheureusement on ne maîtrise pas tout au niveau des machines, notamment l’espace disque… On va donc forcément avoir de nouveau le pb à l’avenir.
Une fois le pb d’espace disque réglé un “sim refresh” ne devrait-il pas réinjecter le bon fichier?

[david (David AZOULAY)]

Je vais regarder comment améliorer la (re)génération de ce fichier mais, comme je l’ai dit, ce n’est que la partie visible de l’iceberg : en cas de file system full il peut potentiellement y avoir d’autres pbs…

[david (David AZOULAY)]

Voilà c’est fait et c’est poussé => le fichier est directement altéré plutôt que de passer par un fichier temporaire. En cas de file système full il restera à priori en l’état et au sim refresh suivant ce sera bon

Mais bon ça ne veut pas dire que ce sera globalement plus robuste au file system full.

[crb-admin]

merci! Mais oui le file system full on essaie d’éviter, après ce sont nos collègues de l’exploitation qui s’occupent des machines et ne provisionnent pas forcément la bonne quantité d’espace disque… Ils m’ont expliqué que leur master de machines est prévu pour avoir de la place à divers endroits (/var, …) mais pas dans /home.

[david (David AZOULAY)]

En général ce qui fait exploser le disque c’est surtout les sauvegardes qui se font automatiquement lors des upgrades ou manuellement et/ou lors des auto save (en standard c’est dans /var/simplicite/save et /var/save/backup chez vous je sais pas)

Il y a des variables de configuration pour jouer sur ces sauvegardes, cf. https://docs.simplicite.io/documentation/90-operation/manager.md#config