2 process en cours de fermeture (1min30) ?

Support Debian
#1

Bonjour,

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.

Que se passe-t-il sur ma machine ?
Merci.

#2

Ça pourrait être pas mal de choses…

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 :

sudo apt-get update && sudo apt-get upgrade

?

4 - Enfin, que renvoie la commande :

cat /proc/version

?

#3

Salut
Si tu n’arrives pas à déterminer les process fautifs tu peux réduire la tempo d’attente

ça se passe dans /etc/systemd/system.conf

il faut décommenter DefaultTimeoutStopSec

Exemple j’ai réduis à 5 secondes, ce qui est déjà un temps fou dans le monde informatique :grinning:

DefaultTimeoutStopSec=5s

#4

Tu veux dire quoi ? Comment as-tu contrôlé ton ordi ?

#5

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é :slight_smile:

je pense a posteriori qu’il s’agit souvent d’un problème de liaison internet ; je m’explique :slight_smile: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

Pas sur que ça t’aide :slight_smile:

#6

Bonjour,

Je suis désolé de répondre tardivement. Mon agenda était un peu overbooké … comme bien des retraités :wink:

@Leobo :

  1. La commande
    [Journal] Storage=auto
    était commentée (un # devant la commande) . J’ai écrit la commande que tu suggères :
    [Journal] Storage=persistent
  2. Je vois dès que le cas de figure se représente.
  3. J’ai exécuté les deux commandes de mise à jour des paquets.
  4. 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 :wink:

@Almtesh
Antivirus Avast et analyse complète.

@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 :wink:

Merci pour toutes vos suggestions.
Je teste et reviens bientôt.
A+

#7

Dans la mesure ou il s’agit d’arrêter l’ordi je ne vois pas où est le risque de faire vite :wink:

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.

https://www.freedesktop.org/software/systemd/man/systemctl.html#

#8

@grandtoubab

Merci pour l’info.
Je vois ce que me retourne Storage et en fonction de la réponse, je reviens avec ces infos ou mes actions.

Merci.

#9

Bonjour.

@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 :wink:

A+

#10

Envoies-en un bout voir si c’est du langage humain. :face_with_raised_eyebrow:

Ou sinon un p’tit

$ sudo journalctl

peut aussi donner des infos.

#11

Bonsoir,

@Leobo :
Un bout de fichier :

_SOURCE_MONOTONIC_TIMESTAMP=0
\UffffffffU
_TRANSPORT=kernel
PRIORITY=5

etc.

journalclt donne ceci :

Un bout de fichier :

-- Logs begin at Mon 2018-05-07 07:50:40 CEST, end at Mon 2018-05-07 16:23:19 CEST. --
mai 07 07:50:40 MGD1117 kernel: 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
mai 07 07:50:40 MGD1117 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 root=UUID=681298ea-5316-4bb0-8c2f-ddc508509080 ro quiet
mai 07 07:50:40 MGD1117 kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
mai 07 07:50:40 MGD1117 kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
mai 07 07:50:40 MGD1117 kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
mai 07 07:50:40 MGD1117 kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
mai 07 07:50:40 MGD1117 kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
mai 07 07:50:40 MGD1117 kernel: x86/fpu: Using 'eager' FPU context switches.
mai 07 07:50:40 MGD1117 kernel: e820: BIOS-provided physical RAM map:
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cbf91fff] usable
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000cbf92000-0x00000000cbf98fff] ACPI NVS
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000cbf99000-0x00000000cc3f2fff] usable
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000cc3f3000-0x00000000cc836fff] reserved
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000cc837000-0x00000000ddd30fff] usable
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000ddd31000-0x00000000ddf18fff] reserved
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000ddf19000-0x00000000ddf38fff] ACPI data
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000ddf39000-0x00000000de45cfff] ACPI NVS
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000de45d000-0x00000000deffefff] reserved
mai 07 07:50:40 MGD1117 kernel: BIOS-e820: [mem 0x00000000defff000-0x00000000deffffff] usable`

A+

#12

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).

#13

Bonsoir Leobo,

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.

A+

#14

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.

#15

Bonjour Leobo,

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à :relaxed::relaxed:

Désolé pour le travail que je vous ai donné à cause de cet oubli.

Un tout grand MERCI pour vos aides précieuses.
A+