Depuis l’installation de Debian 9 sur ma machine après un formatage de la partition Root, lors de l’arrêt de ma machine en fin de journée, je reçois un message lorsque la console est affichée (fond noir et texte en blanc où je n’ai pas d’accès) qui me dite que un ou deux processus sont en cours d’arrêt et que cela prendra 1min30 pour l’un et 2 minutes pour l’autre.
Lors que celui de 1min30 a terminé son cycle d’arrêt, les deux processus se terminent et l’ordinateur termine la procédure d’arrêt.
J’ai contrôlé mon ordi et n’ai détecté aucun virus ni autre indésirable.
Je n’ai rien constaté d’autre d’anormal dans le fonctionnement de ma machine ralentissement, saturation de mémoire, processus qui s’accapare le temps d’un ou des deux corps de mon processeur, etc.
J’ai installé une sauvegarde automatique via Déja-Dup qui s’exécute en début de cession, mais elle n’a jamais provoqué ceci par le passé sur les versions 7 et 8 de Debian.
Ce type de “problème” existe également sur d’autres machines de personnes de mon entourage qui, elles aussi ne comprennent pas ce que c’est.
1 - Tout d’abord, que disent les logs à /var/log/journal/ ?
1 bis - Si jamais il manque des données sur la fermeture de l’ordi, il est possible de rendre persistantes les entrées en éditant /etc/systemd/journald.conf et en remplaçant
[Journal]
Storage=auto
par
[Journal]
Storage=persistent
À la prochaine fermeture, il devrait s’enregistrer davantage d’infos.
2 - Ensuite : les processus en cours de fermeture sont-ils explicitement nommés ?
2 bis - Si oui, peux-tu nous dire desquels il s’agit ?
3 - As-tu fait une mise à jour complète des paquets après la migration :
salut
ton message n’est pas précis mais j’ai déjà eu des trucs comme ça plusieurs fois sur des configs très diffrentes.
le message de grandtoubab m’aurait bien aidé
je pense a posteriori qu’il s’agit souvent d’un problème de liaison internet ; je m’explique un processus cherche à se connecter mais n’y arrive pas, par exemple une mauvaise configuration dans /etc/network/interfaces , ou un fil débranché … et l’ordi attend une réponse positive au lieu de continuer comme d’habitude
La commande [Journal] Storage=auto
était commentée (un # devant la commande) . J’ai écrit la commande que tu suggères : [Journal] Storage=persistent
Je vois dès que le cas de figure se représente.
J’ai exécuté les deux commandes de mise à jour des paquets.
La commande retourne : Linux version 4.9.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.88-1 (2018-04-29)
@grandtoubab
J’ai décommenté mais laisse à 60 sec pour le moment pour tester
@dindoun
J’ai contrôlé toutes les connexions : elles semblent correctes.
Pour ce qui est du réglage de etc/network/interfaces … je n’y connais rien et donc pour le moment … je ne touche pas
Merci pour toutes vos suggestions.
Je teste et reviens bientôt.
A+
Dans la mesure ou il s’agit d’arrêter l’ordi je ne vois pas où est le risque de faire vite
Pour arrêter , je me suis fait un raccourci clavier avec la commande
systemctl poweroff -i
-i, --ignore-inhibitors When system shutdown or a sleep state is requested, ignore inhibitor locks. Applications can establish inhibitor locks to avoid that certain important operations (such as CD burning or suchlike) are interrupted by system shutdown or a sleep state. Any user may take these locks and privileged users may override these locks. If any locks are taken, shutdown and sleep state requests will normally fail (regardless of whether privileged or not) and a list of active locks is printed. However, if --ignore-inhibitors is specified, the locks are ignored and not printed, and the operation attempted anyway, possibly requiring additional privileges.
@Leobo : je viens de jeter un oeil dans /var/log/journal. Il y a 2 fichiers : system.journal et user-1000.journal mais ils sont totalement incompréhensibles pour mes pauvres neurones.
@grandtoubab : même en mettant DefaultTimeoutStopSpec à 60s, l’ordi attend encore 90 sec
Ok, ça n’apporte pas grand chose.
Éteins/rallume (au passage essaie de voir si les processus qui coincent sont nommés, ça aiderait beaucoup !).
Au démarrage, en console :
$ sudo nano /var/log/messages
Le fichier sera sans doute très long. Si jamais tu n’arrives pas à le lire, télécharge-le sur le forum pour qu’on puisse y jeter un œil (mais ne copie-colle pas sinon ton post va faire deux bornes de long).
Quand je regarde via la commande que tu suggères, il n’y a que des infos sur ce qu’il se passe dans cette cession. On ne voir rien sur celle d’hier quand qu’ai fermé la cession et qu’il y a eu un délai avant le fermeture.
Ce fichier présente des logs avec une limite de temps, c’est pour cela que je te proposais de faire un redémarrage (cf mon post précédent), histoire qu’il récupère des infos fraîches et aussi pour que tu regardes au moment de l’extinction si les processus bloquants sont explicitement identifiés ou non.
Grâce à tes suggestions et la présence d’un ami qui connaît Linux un peu mieux que moi, on a mis la main sur le “coupable” : c’est tout simplement la sauvegarde incrémentale qui a lieu à la fermeture de l’ordi.
J’avais honteusement oublié que j’avais une sauvegarde à ce moment-là
Désolé pour le travail que je vous ai donné à cause de cet oubli.
