Matériel: PC fixe
Version de YunoHost: 3.8.4.8
J’ai accès à mon serveur : complet
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Bonjour,
Pixelfed et framaform sont tombés en panne. Elles semblent avoir pour point commun. Framaforms me dit explicitement PDOException: could not find driver in lock_may_be_available() (line 167 of /var/www/framaforms/includes/lock.inc). et pixelfed me donne un message d’erreur similaire quand je lance “php artisan migrate”.
Quand je désinstalle framaforms, pixelfed se remet à fonctionner, et framaforms refonctionne à son tour quand je le réinstalle. Jusqu’à la fois suivante, où la panne revient de façon aléatoire.
Eventuellement on peut voir ça si on regarde le log d’install de pixelfed … Ou alors il s’est passé un truc entre temps et on devrait pouvoir le voir dans les logs d’apt (qui trainent dans /var/log/apt si je m’trompe pas)
Ce qui est bizarre, c’est que les apps fonctionnent la majorité du temps et cette panne survient de nulle-part. Comment un module peut-il disparaître de la sorte ?
Tu peux trouver les historiques d’apt liés à php7.3-pgsql avec :
for LOG in /var/log/apt/history*; do zgrep -C 3 "php7.3-pgsql" $LOG; done
Déjà on est pas sur que ce soit ça exactement, et le truc c’est qu’il faut arrêter avec cette idée que l’informatique “ça tombe en marche et ça continue de marcher pour toujours si on y touche pas”
On peut croire qu’on a “rien touché” alors qu’en fait on a fait pleins de trucs et qu’une bricole peut avoir une réaction en chaîne inattendue. Des fois une conf n’est pas bien propagée alors un truc continue de fonctionner, et puis un jour deux mois plus tard un “reload” propage le truc et ça casse et on comprends pas. Et puis même en admettant qu’on y touche pas, un serveur c’est un “écosystème vivant” et il se passe quand même des trucs en permanence. Il y a des cron job qui tourne, potentiellement des mise à jour automatique, de la RAM qui est utilisé alors un service crashe car plus de RAM, alors peut-être il est relancé automatiquement et que ça a des impacts.
Clairement c’est rageant parce que j’suis en train de dire que tout est mystique et pas formel, mais c’est en tout cas un peu le paradigme de l’administration système en l’état…
sauf que ça ne dit pas le contexte, donc il faudrait corréler ça aux logs d’install/remove des apps …
donc par exemple si on prends la suppression qui a eu lieu de 2020-06-11 (hier) vers 17:10:57, est-ce que tu peux trouver une opération qui aurait lieu au même moment dans les logs de yunohost ?
(Attention pour l’heure, des fois il y a un décalage de +/- une ou deux heure avec le fuseau horaire etc… donc ca peut etre aussi 15h10, 16h10, 18h10 ou 19h10)
J’ai jeté un oeil dans journalctl, mais il ne remonte pas assez loin.
Je sais juste que ça se débloque au moment où la sortie affiche “create database”. Mais je ne sais pas comment retrouver la commande précise qui a décoincé le bazar.
J’y ai pensé aussi, mais je n’ai pas trouvé le log qui me permette de savoir précisément ce qui a relancé pixelfed, sachant que regarder le log d’installation de framaform ne m’en a pas appris davantage.
OK, je viens d’apprendre que framaforms était de “faible qualité”, donc c’est pas impossible qu’elle foute le dawa à cause de ça. Je vais la désinstaller et voir si le stuut avec pixelfed se reproduit.
EDI: c’était pas ça, pixelfed est à nouveau en panne. J’ai tenté de redémarrer postgresql, mais ça n’a pas marché.
Bon ben du coup les dépendances php qui devraient être dans Depends: ne sont pas là, c’est la cause du bug … j’ai tenté une install de mon côté et je reproduis le bug donc je vais creuser ce que les helpers font pour comprendre …
En attendant tu peux t’en sortir en installant manuellement php7.3-pgsql