Erreur de mise à jour système (php7.3-fpm)

Bonjour à tous !

Je possède une brique internet aec VPN avec yunohost 3.8.5.9 dessus

J’ai accès à mon serveur en SSH et par la webadmin.

Description du problème

J’ai fait une mise à jour (comme j’en fais souvent), et le système php7.3-fpm a échoué dans sa mise à jour. Le bandeau d’information du webadmin m’a suggéré des commandes pour réparer l’erreur, je les ai suivies, mais les routines ont échoué et cela n’a rien changé.

Le reste continuant de fonctionner, j’ai laissé ça de côté pour m’en occuper plus tard, sauf que maintenant, j’ai de nouvelles erreurs !

Quand j’essaie de faire une mise à jour système, j’obtiens ceci : (je précise que cette fois j’ai fait la mise à jour en ligne de commande, avec " yunohost tools upgrade --system"

Voici ce que j’obtiens dans le log :

args:
  apps: null
  system: true
ended_at: 2020-11-13 19:11:50.284245
error: "Impossible de mettre \xE0 jour tous les paquets"
operation: tools_upgrade
related_to: []
started_at: 2020-11-13 19:11:41.930673
success: false
yunohost_version: 3.8.5.9

============

2020-11-13 20:11:41,973: INFO - Mise à jour des paquets du système (non liés a YunoHost)…
2020-11-13 20:11:44,555: DEBUG - Running apt command :
DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none apt-get --fix-broken --show-upgraded --assume-yes --quiet -o=Dpkg::Use-Pty=0 -o Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-confmiss" -o Dpkg::Options::="--force-confdef" dist-upgrade
2020-11-13 20:11:44,998: INFO - + Lecture des listes de paquets…
2020-11-13 20:11:46,112: INFO - + Construction de l'arbre des dépendances…
2020-11-13 20:11:46,116: INFO - + Lecture des informations d'état…
2020-11-13 20:11:47,128: INFO - + Calcul de la mise à jour…
2020-11-13 20:11:48,342: INFO - + Les paquets suivants seront mis à jour :
2020-11-13 20:11:48,346: INFO - +   php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-intl
2020-11-13 20:11:48,350: INFO - +   php7.4-json php7.4-ldap php7.4-mbstring php7.4-mysql php7.4-opcache
2020-11-13 20:11:48,354: INFO - +   php7.4-readline php7.4-xml php7.4-zip
2020-11-13 20:11:48,459: INFO - + 14 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
2020-11-13 20:11:48,462: WARNING - E: Pas assez d'espace disponible sur /var/cache/apt/archives/
2020-11-13 20:11:48,465: INFO - + Il est nécessaire de prendre 3 923 ko dans les archives.
2020-11-13 20:11:48,468: INFO - + Après cette opération, 1 024 o d'espace disque supplémentaires seront utilisés.
2020-11-13 20:11:50,280: WARNING - Impossible de mettre à jour les paquets suivants : php7.4-cli, php7.4-common, php7.4-curl, php7.4-fpm, php7.4-gd, php7.4-intl, php7.4-json, php7.4-ldap, php7.4-mbstring, php7.4-mysql, php7.4-opcache, php7.4-readline, php7.4-xml, php7.4-zip

Merci beaucoup pour toute aide éventuelle !
Mon autre souci (lié je suppose) est que maintenant j’obtiens des “erreur 502 bad gateway” quand je veux accéder à certaines de mes applis…

Il faut probablement que tu libères de la place sur ta carte SD avant de faire quoique ce soit.
Peux-tu nous montrer l’utilisation de ton espace disque avec la commande df -h ?

Voilà :

root@smidge:~# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               484M       0  484M   0% /dev
tmpfs              101M     11M   90M  11% /run
/dev/mmcblk0p1      30G     30G     0 100% /
tmpfs              501M     76K  501M   1% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              501M       0  501M   0% /sys/fs/cgroup
tmpfs              101M       0  101M   0% /run/user/0

Ma carte SD fait 32 Go.

Je me doute que le problème vient de la ligne “/dev/mmcblk0p1 30G 30G 0 100% /”, sauf qu’après exploration manuelle, le fichier en question fait… 0 Ko…

OK, je vois que tu n’as pas de partitionnement ésotérique. Tout est dans une seule partition. Donc maintenant il faut identifier dans quel(s) dossier(s) on peut libérer de la place. Pour ça on utilise la commande du (disk usage).

sudo du -sh /*

Cette commande nous donnera l’espace disque occupé par chaque sous-dossier de la racine. Ensuite il faudra affiner. Par exemple si on voit que le dossier /var occupe beaucoup de place, on peut alors analyser ses sous-dossiers :

sudo du -sh /var/*

Et ainsi de suite.


PS: Pour info, les fichiers que tu trouves dans /dev/ ne sont pas vraiment des fichiers normaux, c’est pour ça que la taille du fichier /dev/mmcblk0p1 n’est pas représentative et qu’on doit utiliser la commande du.

Merci pour l’astuce.
J’ai trouvé où était le problème, mais cela n’a hélas pas tout solutionné.
J’avais un fichier log qui faisait pas loin de 20 Go et qui m’avais bouffé tout l’espace.

Hélas, je pense que c’était un symptôme d’un autre problème de mise à jour (qui m’a gavé mon log jusqu’à saturation de l’espace), que je place ici.
Quand je lance la mise à jour sur le webadmin, ça me dit ça :

Vous ne pouvez pas faire ça maintenant car dpkg/apt (le gestionnaire de paquets du système) semble avoir laissé des choses non configurées. Vous pouvez essayer de résoudre ce problème en vous connectant via SSH et en exécutant sudo apt install --fix-broken et/ou `sudo dpkg --configure -a’.

Et voici ce que j’obtiens quand je lance les commandes proposées :

root@smidge:~# sudo apt install --fix-broken
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  linux-image-4.9.0-12-armmp
Veuillez utiliser « sudo apt autoremove » pour le supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Paramétrage de php7.0-fpm (7.0.33-37+0~20201103.43+debian9~1.gbp25a3d7) ...
Job for php7.0-fpm.service failed because the control process exited with error code.
See "systemctl status php7.0-fpm.service" and "journalctl -xe" for details.
invoke-rc.d: initscript php7.0-fpm, action "restart" failed.
● php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-11-14 15:05:59 CET; 79ms ago
     Docs: man:php-fpm7.0(8)
  Process: 16020 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.0/fpm/pool.d/www.conf 70 (code=exited, status=0/SUCCESS)
  Process: 16018 ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf (code=exited, status=78)
 Main PID: 16018 (code=exited, status=78)

nov. 14 15:05:58 smidge.noho.st systemd[1]: Starting The PHP 7.0 FastCGI Pro…...
nov. 14 15:05:59 smidge.noho.st php-fpm7.0[16018]: [14-Nov-2020 15:05:59] WAR…em
nov. 14 15:05:59 smidge.noho.st php-fpm7.0[16018]: [14-Nov-2020 15:05:59] ERR…ck
nov. 14 15:05:59 smidge.noho.st php-fpm7.0[16018]: [14-Nov-2020 15:05:59] ERR…ed
nov. 14 15:05:59 smidge.noho.st systemd[1]: php7.0-fpm.service: Main process…n/a
nov. 14 15:05:59 smidge.noho.st systemd[1]: Failed to start The PHP 7.0 Fast…er.
nov. 14 15:05:59 smidge.noho.st systemd[1]: php7.0-fpm.service: Unit entered…te.
nov. 14 15:05:59 smidge.noho.st systemd[1]: php7.0-fpm.service: Failed with …e'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: erreur de traitement du paquet php7.0-fpm (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
 php7.0-fpm
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@smidge:~# sudo dpkg --configure -a
Paramétrage de php7.0-fpm (7.0.33-37+0~20201103.43+debian9~1.gbp25a3d7) ...
Job for php7.0-fpm.service failed because the control process exited with error code.
See "systemctl status php7.0-fpm.service" and "journalctl -xe" for details.
invoke-rc.d: initscript php7.0-fpm, action "restart" failed.
● php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-11-14 15:29:58 CET; 82ms ago
     Docs: man:php-fpm7.0(8)
  Process: 18438 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.0/fpm/pool.d/www.conf 70 (code=exited, status=0/SUCCESS)
  Process: 18428 ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf (code=exited, status=78)
 Main PID: 18428 (code=exited, status=78)

nov. 14 15:29:57 smidge.noho.st systemd[1]: Starting The PHP 7.0 FastCGI Pro…...
nov. 14 15:29:57 smidge.noho.st php-fpm7.0[18428]: [14-Nov-2020 15:29:57] WAR…em
nov. 14 15:29:57 smidge.noho.st php-fpm7.0[18428]: [14-Nov-2020 15:29:57] ERR…ck
nov. 14 15:29:57 smidge.noho.st php-fpm7.0[18428]: [14-Nov-2020 15:29:57] ERR…ed
nov. 14 15:29:58 smidge.noho.st systemd[1]: php7.0-fpm.service: Main process…n/a
nov. 14 15:29:58 smidge.noho.st systemd[1]: Failed to start The PHP 7.0 Fast…er.
nov. 14 15:29:58 smidge.noho.st systemd[1]: php7.0-fpm.service: Unit entered…te.
nov. 14 15:29:58 smidge.noho.st systemd[1]: php7.0-fpm.service: Failed with …e'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: erreur de traitement du paquet php7.0-fpm (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
 php7.0-fpm

Il faut qu’on trouve pourquoi le service php7.0-fpm refuse de se relancer.
Malheureusement les logs que tu as copiés ci-dessus sont tronqués sur la droite.
Peux-tu relancer manuellement le service, puis afficher ses derniers logs en entier ?

systemctl restart php7.0-fpm
tail -n 50 /var/log/php7.0-fpm.log

Voilà ce que ça donne :

root@smidge:~# systemctl restart php7.0-fpm
Job for php7.0-fpm.service failed because the control process exited with error code.
See "systemctl status php7.0-fpm.service" and "journalctl -xe" for details.

root@smidge:~# tail -n 50 /var/log/php7.0-fpm.log
[08-Nov-2020 06:25:23] NOTICE: error log file re-opened
[13-Nov-2020 19:17:33] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[13-Nov-2020 19:17:34] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-baikal.sock
[13-Nov-2020 19:17:35] ERROR: FPM initialization failed
[13-Nov-2020 19:39:03] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[13-Nov-2020 19:39:03] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-baikal.sock
[13-Nov-2020 19:39:03] ERROR: FPM initialization failed
[13-Nov-2020 19:46:16] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[13-Nov-2020 19:46:16] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

[14-Nov-2020 07:08:00] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 07:08:00] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

[14-Nov-2020 15:00:27] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 15:00:27] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-baikal.sock
[14-Nov-2020 15:00:27] ERROR: FPM initialization failed
[14-Nov-2020 15:05:59] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 15:05:59] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-baikal.sock
[14-Nov-2020 15:05:59] ERROR: FPM initialization failed
[14-Nov-2020 15:29:57] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 15:29:57] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-baikal.sock
[14-Nov-2020 15:29:57] ERROR: FPM initialization failed
[14-Nov-2020 19:07:31] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 19:07:31] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

[14-Nov-2020 23:57:40] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 23:57:40] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

[14-Nov-2020 23:58:04] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[14-Nov-2020 23:58:04] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

[15-Nov-2020 07:13:17] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[15-Nov-2020 07:13:17] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

[15-Nov-2020 10:19:35] WARNING: [pool limesurvey] 'request_slowlog_timeout' is not supported on your system
[15-Nov-2020 10:19:35] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-baikal.sock
[15-Nov-2020 10:19:35] ERROR: FPM initialization failed

Hmmm, je soupçonne que tu as un service php7.3-fpm qui tourne sur ta brique, en plus du service php7.0-fpm. Si c’est le cas, je serais tenté de désinstaller complètement php7.0-fpm car il est probable qu’il ne serve plus à rien, sinon créer des problèmes. Mais avant d’en arriver là, je propose de faire du nettoyage.

Normalement, chaque application PHP installée sur yunohost créé un fichier de configuration dans le ou les dossiers /etc/php/7.?/fpm/pool.d/ (le ? pouvant être 0 ou 3 ici).
Pour lister toutes ces configs, tape ça :

ls -l /etc/php/7.?/fpm/pool.d/

À priori on devrait trouver un fichier baikal.conf en double. Si c’est le cas, alors on va supprimer celui qui est en trop (celui qui est dans php7.0) :
(en fait, plutôt que de le supprimer, on va le déplacer dans /tmp/, au cas où on aurait besoin de le restaurer)

mv /etc/php/7.0/fpm/pool.d/baikal.conf /tmp/

Fais la même chose avec les éventuels autres fichiers de configuration en doublon puis relance le service :

systemctl restart php7.0-fpm

Cette fois ça devrait passer, auquel cas tu pourras alors enfin relancer la commande dpkg --configure -a qui échouait précédemment à cause du service php7.0-fpm.

C’était bien ça, le problème est réglé !

Merci beaucoup !!