Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Machine Jessie ne s'arrête pas

16 réponses
Avatar
Sébastien NOBILI
Bonjour,

J'ai un comportement qui me rappelle une discussion qui avait eu lieu ici :

https://lists.debian.org/5405C1F1.80100@nativobject.net

Quelques différences tout de même :
- je n'utilise pas KDE mais Fluxbox et j'éteins (enfin plutôt j'essaye) ma
machine en appuyant sur le bouton d'alimentation qui est géré par les
couches ACPI du système (il n'y a pas de fenêtre de déconnexion, quand on
appuie sur le bouton ça lance l'extinction du système);
- je tombe aussi sur un écran noir mais aucun moyen de retourner sur une
console (le moniteur se met même en veille);
- ça semble très dépendant de l'uptime du système, si je l'arrête dès
l'ouverture de session, tout va bien, si je l'arrête en fin de journée, il
reste bloqué;
- j'ai tenté « halt », « shutdown » et « systemctl shutdown », même
comportement.

J'aimerais déjà identifier ce qui bloque. Comment récupérer les messages du
dernier arrêt du système (et éventuellement des précédents) ?

L'écran noir pourrait être lié au couple Xorg/nouveau car j'ai déjà tenté
d'arrêter le serveur X (arrêt du service LightDM) avant d'arrêter le système et
j'ai également abouti à un écran noir sans possibilité de passer sur une
console. Est-ce que ça évoque quelque chose à quelqu'un ?

Parmi les subtilités de mon système :

- j'ai une session tmux ouverte avec de nombreuses fenêtres qui semble
introduire un délai dans l'extinction (dans les tests qui marchent -
extinction dès l'ouverture de session donc - on voit Systemd attendre
1min30 la fin des tâches liées à mon compte utilisateur);
- j'ai au moins un conteneur LXC avec un pont réseau (mais si j'arrête le
conteneur avant de déclencher l'arrêt du système, le comportement est le
même).

Toute piste sera la bienvenue (hormis celles consistant à désinstaller Systemd,
merci d'avance de vous abstenir).

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20150622091454.GB3924@sebian.nob900.homeip.net

10 réponses

1 2
Avatar
honeyshell
Bonjour Sébastien,

As tu plus d'infos à fournir à partir de ton /var/log/messages?
Il doit surement contenir une erreur pour nous guider.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAJeHwDYRD5+HQUD-_=Xka95=VYo2+kg+dQT=
Avatar
S
Le lundi 22 juin 2015 à 13:21, honeyshell a écrit :
As tu plus d'infos à fournir à partir de ton /var/log/messages?



Ben non, il n'y a rien d'intéressant au moment de ma dernière tentative échouée
d'extinction… Cette tentative était vendredi vers 17h50. Dans
/var/log/messages.1 j'ai des messages à 16h30 (donc sans rapport) puis :

autossh[3896]: received signal to exit (15)
rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="1279" x-info="http://www.rsyslog.com"] exiting on signal 15.

Dans /var/log/syslog.1 pas grand-chose de plus intéressant :

autossh[3896]: received signal to exit (15)
hwclock[19330]: hwclock from util-linux 2.25.2
hwclock[19330]: Using the /dev interface to the clock.
hwclock[19330]: Last drift adjustment done at 1434641718 seconds after 1969
hwclock[19330]: Last calibration done at 1434641718 seconds after 1969
hwclock[19330]: Hardware clock is on UTC time
hwclock[19330]: Assuming hardware clock is kept in UTC time.
hwclock[19330]: Waiting for clock tick...
hwclock[19330]: ...got clock tick
hwclock[19330]: Time read from Hardware Clock: 2015/06/19 15:49:23
hwclock[19330]: Hw clock time : 2015/06/19 15:49:23 = 1434728963 seconds since 1969
hwclock[19330]: missed it - 1434728961.659161 is too far past 1434728961.500000 (0.159161 > 0.001000)
hwclock[19330]: 1434728962.500000 is close enough to 1434728962.500000 (0.000000 < 0.002000)
hwclock[19330]: Set RTC to 1434728962 (1434728961 + 1; refsystime = 1434728961.000000)
hwclock[19330]: Setting Hardware Clock to 15:49:22 = 1434728962 seconds since 1969
hwclock[19330]: ioctl(RTC_SET_TIME) was successful.
hwclock[19330]: Clock drifted -0.1 seconds in the past 87243 seconds in spite of a drift factor of -1.847204 seconds/day.
hwclock[19330]: Adjusting drift factor by -0.070171 seconds/day
systemd[3248]: Stopping Default.
systemd[3248]: Stopped target Default.
systemd[3248]: Stopping Basic System.
systemd[3248]: Stopped target Basic System.
systemd[3248]: Stopping Paths.
systemd[3248]: Stopped target Paths.
systemd[3248]: Stopping Timers.
systemd[3248]: Stopped target Timers.
systemd[3248]: Stopping Sockets.
systemd[3248]: Stopped target Sockets.
systemd[3248]: Starting Shutdown.
rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="1279" x-info="http://www.rsyslog.com"] exiting on signal 15.

J'ai également tenté « journalctl --since 15-06-18 » mais il ne m'affiche que
les logs depuis le dernier boot (ce matin donc)…

Il doit surement contenir une erreur pour nous guider.



Oui, j'espère qu'on va la trouver ;-)

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
honeyshell
suite à cette lecture :http://crunchbang.org/forums/viewtopic.php?id 844

peux tu essayer un sudo umount -a avant extinction pour être sur que
c'est pas un point de montage qui est en cause?

2015-06-22 14:05 GMT+02:00 Sébastien NOBILI :
Le lundi 22 juin 2015 à 13:21, honeyshell a écrit :
As tu plus d'infos à fournir à partir de ton /var/log/messages ?



Ben non, il n'y a rien d'intéressant au moment de ma dernière t entative échouée
d'extinction… Cette tentative était vendredi vers 17h50. Dan s
/var/log/messages.1 j'ai des messages à 16h30 (donc sans rapport) pu is :

autossh[3896]: received signal to exit (15)
rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid=" 1279" x-info="http://www.rsyslog.com"] exiting on signal 15.

Dans /var/log/syslog.1 pas grand-chose de plus intéressant :

autossh[3896]: received signal to exit (15)
hwclock[19330]: hwclock from util-linux 2.25.2
hwclock[19330]: Using the /dev interface to the clock.
hwclock[19330]: Last drift adjustment done at 1434641718 seconds afte r 1969
hwclock[19330]: Last calibration done at 1434641718 seconds after 196 9
hwclock[19330]: Hardware clock is on UTC time
hwclock[19330]: Assuming hardware clock is kept in UTC time.
hwclock[19330]: Waiting for clock tick...
hwclock[19330]: ...got clock tick
hwclock[19330]: Time read from Hardware Clock: 2015/06/19 15:49:23
hwclock[19330]: Hw clock time : 2015/06/19 15:49:23 = 1434728963 se conds since 1969
hwclock[19330]: missed it - 1434728961.659161 is too far past 1434728 961.500000 (0.159161 > 0.001000)
hwclock[19330]: 1434728962.500000 is close enough to 1434728962.50000 0 (0.000000 < 0.002000)
hwclock[19330]: Set RTC to 1434728962 (1434728961 + 1; refsystime = 1434728961.000000)
hwclock[19330]: Setting Hardware Clock to 15:49:22 = 1434728962 sec onds since 1969
hwclock[19330]: ioctl(RTC_SET_TIME) was successful.
hwclock[19330]: Clock drifted -0.1 seconds in the past 87243 seconds in spite of a drift factor of -1.847204 seconds/day.
hwclock[19330]: Adjusting drift factor by -0.070171 seconds/day
systemd[3248]: Stopping Default.
systemd[3248]: Stopped target Default.
systemd[3248]: Stopping Basic System.
systemd[3248]: Stopped target Basic System.
systemd[3248]: Stopping Paths.
systemd[3248]: Stopped target Paths.
systemd[3248]: Stopping Timers.
systemd[3248]: Stopped target Timers.
systemd[3248]: Stopping Sockets.
systemd[3248]: Stopped target Sockets.
systemd[3248]: Starting Shutdown.
rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid=" 1279" x-info="http://www.rsyslog.com"] exiting on signal 15.

J'ai également tenté « journalctl --since 15-06-18  » mais il ne m'affiche que
les logs depuis le dernier boot (ce matin donc)…

Il doit surement contenir une erreur pour nous guider.



Oui, j'espère qu'on va la trouver ;-)

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/ eip.net




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAJeHwDby-aYqGfWiZL0MXw0KTYZfPY5cJs565ayAuOaZ+
Avatar
S
Le lundi 22 juin 2015 à 14:49, honeyshell a écrit :
suite à cette lecture :http://crunchbang.org/forums/viewtopic.php?id844



Merci pour la lecture.

peux tu essayer un sudo umount -a avant extinction pour être sur que
c'est pas un point de montage qui est en cause?



Ça ne devrait pas, tous mes points de montage (automatique) sont montés :

$ mount | wc -l
36

$ mount -a
[erreurs car certains sont déjà montés]

$ mount | wc -l
36

Tentons l'extinction maintenant…

Pas mieux. Écran noir, LED figées. La machine répond au ping mais le serveur SSH
n'est pas accessible.

Petite précision le système est sur un disque externe (USB3). J'ai récemment
ajouté une carte USB3 à ma machine pour gagner en réactivité, pourtant je crois
bien que le problème était déjà là avant. Je repasse sur les ports USB de la
carte mère pour voir si ça arrange les choses.

En attendant, si quelqu'un sait comment extraire les messages d'extinction du
boot précédent en utilisant journalctl…

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
S
Le lundi 22 juin 2015 à 15:33, Sébastien NOBILI a écrit :
En attendant, si quelqu'un sait comment extraire les messages d'extinction du
boot précédent en utilisant journalctl…



Facile, RTFM !

journald.conf(5) :

Storage Controls where to store journal data. One of
"volatile", "persistent", "auto" and "none". If
"volatile", journal log data will be stored only
in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed). If
"persistent", data will be stored preferably on
disk, i.e. below the /var/log/journal hierarchy
(which is created if needed), with a fallback to
/run/log/journal (which is created if needed),
during early boot and if the disk is not writable.
"auto" is similar to "persistent" but the
directory /var/log/journal is not created if
needed, so that its existence controls where log
data goes. "none" turns off all storage, all log
data received will be dropped. Forwarding to other
targets, such as the console, the kernel log
buffer or a syslog daemon will still work however.
Defaults to "auto".

Si le dossier « /var/log/journal » existe, les logs seront persistents, sinon
volatiles. Le dossier n'existant pas par défaut, ils sont volatiles.

Je viens de le créer, on verra si il y a des choses intéressantes au prochain
boot.

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
honeyshell
source : http://askubuntu.com/questions/103015/how-do-i-check-if-last-shutdown-was-clean
oui je sais que tu n'aimes pas bcp ubuntu ;)))))

un petit script qui pourrait bien espionner ton soucis?

#!/bin/bash
B="1"
touch data_file
echo $(($(grep -nr "$(cat /var/log/kern.log | grep "$(date -d $(who
-b | awk '{printf $3}') '+%b %-d')" | grep imklog | grep $(cat
/var/log/kern.log | grep "$(date -d $(who -b | awk '{printf $3}') '+%b
%-d')" | grep imklog | cut -d' ' -f3 | sort -k1 -r | sort --unique
--stable -k2,3))" /var/log/kern.log | awk '{printf $1}' | grep -oE
"[[:digit:]]{1,}")-$B)) > data_file


if [[

($(sed -n $(cat data_file)p /var/log/kern.log | awk '{print $6}') = "Kernel") &&
($(sed -n $(cat data_file)p /var/log/kern.log | awk '{print $7}') = "logging") &&
($(sed -n $(cat data_file)p /var/log/kern.log | awk '{print $8}') = "(proc)") &&
($(sed -n $(cat data_file)p /var/log/kern.log | awk '{print $9}') == "stopped.")


]]; then

echo Last Shutdown-proper

else

echo Last Shutdown_not proper

fi

rm data_file

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Sébastien NOBILI
Le lundi 22 juin 2015 à 15:41, honeyshell a écrit :
source : http://askubuntu.com/questions/103015/how-do-i-check-if-last-shutdown-was-clean
oui je sais que tu n'aimes pas bcp ubuntu ;)))))




C'est un peu réducteur de dire ça :-)

Disons que j'essaye d'être objectif à son sujet. Oui Ubuntu a fait beaucoup de
bien à Debian, mais non, on ne peut pas prendre Debian testing chaque mois
d'avril et d'octobre et décréter que « c'est stable » !

un petit script qui pourrait bien espionner ton soucis?



Pfiouuuu, ça en fait des « pipes » !

Bon je prends mais je me doute bien de la sentence :

Last Shutdown_not proper

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
honeyshell
le dossier /var/log/journal se crée, puis est détruit à la f ermeture?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
S
Le lundi 22 juin 2015 à 16:25, honeyshell a écrit :
le dossier /var/log/journal se crée, puis est détruit à la fermeture?



Euuuh… RTFM ! (désolé, pas pu m'empêcher :-D)

Non, si le dossier « /var/log/journal » existe alors journald va écrire dedans
et ce sera persistent.

Si le dossier n'existe pas, il écrira dans « /run/log/journal » et ce sera
volatile (puisque « /run » est un montage « tmpfs »).

Bref, c'est bien pensé (caser « Systemd » et « bien pensé » dans un même
message, c'est sûr, je vais me faire des ennemis…).

Sébastien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Anthony Papillon
Bonjour,

Chez moi j'ai des montages réseaux qui demande du délai à l ’arrêt de la machine.
Peut etre regarder du coté des montages en place.

Vu que tu parles de problème suite à l'ouverture de session, si t u
ouvres une session en mode console (hors graphique) tu as le meme
problème ?

--
Anthony

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/CAKLx1A+ORwrgNJFEa36mtzDoOi7c31mi2ozwnR=
1 2