BERTRAND Joël a écrit : > Plus exactement, c'est cette commande qui semble renvoyer un SIGBUS : > ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld > > Je peux pourtant, en root, la lancer à la main (elle s'exécute en root > dans l'unité en question). > > Si je la mets en commentaire, ça se bauge plus loin : > Process: 1084452 ExecStartPre=/bin/sh -c systemctl unset-environment > _WSREP_START_POSITION (code=killed, signal=BUS) > > Ça pue encore le bug systemd. Je vais redémarrer le serveur histoire de > voir si c'est reproductible (parce que ça s'est mis à merdouiller sans > aucune mise à jour). >
Bon. J'ai simplement redémarré le serveur et, miracle, ça fonctionne à nouveau. Sauf que le swap a merdouillé parce que systemd qui DEMANDAIT (sous peine de ne pas lancer iscsi) précédemment ceci : hilbert:[~] > cat /etc/systemd/system/swap.target [Unit] Description=Swap Requires=open-iscsi.service After=open-iscsi.service Documentation=man:systemd.special(7) ne fonctionne plus si la ligne After est spécifiée. Toutes les mises à jour automatique sont naturellement désactivées. Naturellement, un shutdown -r now ne fonctionnait pas, preuve une fois de plus que systemd était parti en vacances. J'avoue que je commence à en avoir assez de ce genre de comportement. À l'époque où il fallait voter pour savoir si on voulait systemd ou pas, j'avais voté non pour tout un tas d'arguments, tas d'arguments qui n'a cessé de grossir depuis. Je ne compte plus le nombre de problèmes directement liés à systemd (ou usrmerge d'ailleurs) dès qu'on n'est plus dans une configuration "machine de bureau". Mes serveurs avec un init SysV ou BSD se font oublier, ceux avec systemd sont à surveiller comme le lait sur le feu. Je trouve à titre personnel déplorable d'avoir à redémarrer une machine Unix pour retrouver un comportement normal. J'ai l'impression qu'il a fallu trente ans d'évolution pour aboutir à un comportement du type Windows... JKB