Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos
entrailles, éclairant ma voie vers la résolution d'un problème qui
commence à me les briser.
Le problème initial est une délai de 1'30'' à l'extinction
[poweroff|reboot] du système, avec les messages systemd :
[***] A stop job is running for ifup for enp4s0 …
[***] A stop job is running for Raise network interfaces …
Bien entendu, dans un premier temps, j'ai écumé le WEB et essayé
les suggestions glanées, mais aucune n'a résolu le problème.
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode :
https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
à la section « Shutdown Completes Eventually ». Las, au démarrage
suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me
voilà à vous demander votre aide pour déboguer mon débogage.
Pour préciser -- les instructions du lien ci-dessus n'étant pas très
détaillées -- j'ai procédé ainsi :
1. Ajout d'un « menuentry » dans « /etc/grub.d/40_custom », identique au
menuentry principal généré automatiquement par Debian, à l'exception de :
linux /boot/vmlinuz-4.9.0-2-amd64 root=UUID=04cab1ac-8020-4069-97ae-f567329ad900 systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0
2. $ sudo update-grub2
3. démarrage du système avec ce « menuentry » de débogage.
4. création du fichier :
/usr/lib/systemd/system-shutdown/debug.sh (-rwxr-xr-x 1 root root)
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
5. redémarrage du système sur le « menuentry » principal.
6. Choux blanc : pas de /shutdown-log.txt ?!
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
maderios
On 02/27/2017 02:11 PM, Alexandre Hoïde wrote:
Chères colistières, chers colistiers, Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos entrailles, éclairant ma voie vers la résolution d'un problème qui commence à me les briser. Le problème initial est une délai de 1'30'' à l'extinction [poweroff|reboot] du système, avec les messages systemd : [***] A stop job is running for ifup for enp4s0 … [***] A stop job is running for Raise network interfaces …
Bonjour Ce problème a été réglé par des utilisateurs en changeant de noyau. Tu peux essayer de booter sur un noyau Stretch Sid sera toujours Sid... :) -- Maderios
On 02/27/2017 02:11 PM, Alexandre Hoïde wrote:
Chères colistières, chers colistiers,
Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos
entrailles, éclairant ma voie vers la résolution d'un problème qui
commence à me les briser.
Le problème initial est une délai de 1'30'' à l'extinction
[poweroff|reboot] du système, avec les messages systemd :
[***] A stop job is running for ifup for enp4s0 …
[***] A stop job is running for Raise network interfaces …
Bonjour
Ce problème a été réglé par des utilisateurs en changeant de noyau.
Tu peux essayer de booter sur un noyau Stretch
Sid sera toujours Sid... :)
Chères colistières, chers colistiers, Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos entrailles, éclairant ma voie vers la résolution d'un problème qui commence à me les briser. Le problème initial est une délai de 1'30'' à l'extinction [poweroff|reboot] du système, avec les messages systemd : [***] A stop job is running for ifup for enp4s0 … [***] A stop job is running for Raise network interfaces …
Bonjour Ce problème a été réglé par des utilisateurs en changeant de noyau. Tu peux essayer de booter sur un noyau Stretch Sid sera toujours Sid... :) -- Maderios
JB
Bonsoir, /sbin/shutdown est un lien vers /bin/systemctl, man systemctl vers la fin on trouve desméthodes d'arret personnellement, je devrais attendre 15' j'ai contourné le pb avec reboot dés l'extintion du clavier, power off de l'ordinateur essayer: trace shutdown et le bon paramètre avant de rebooter, gdb bt ou mise oeuvre de kdump je n'utilise pas votre méthode d'analyse, sous réserve la taille de 1M me parait juste JB Le lundi 27 février 2017 à 14:11 +0100, Alexandre Hoïde a écrit :
Chères colistières, chers colistiers, Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos entrailles, éclairant ma voie vers la résolution d'un problème qui commence à me les briser. Le problème initial est une délai de 1'30'' à l'extinction [poweroff|reboot] du système, avec les messages systemd : [***] A stop job is running for ifup for enp4s0 … [***] A stop job is running for Raise network interfaces … Bien entendu, dans un premier temps, j'ai écumé le WEB et essayé les suggestions glanées, mais aucune n'a résolu le problème. Afin d'en comprendre la cause, j'essaie d'appliquer la méthode : https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 à la section « Shutdown Completes Eventually ». Las, au démarrage suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me voilà à vous demander votre aide pour déboguer mon débogage. Pour préciser -- les instructions du lien ci-dessus n'étant pas très détaillées -- j'ai procédé ainsi : 1. Ajout d'un « menuentry » dans « /etc/grub.d/40_custom », identique au menuentry principal généré automatiquement par Debian, à l'exception de : linux /boot/vmlinuz-4.9.0-2-amd64 root=UUIDcab1ac- 8020-4069-97ae-f567329ad900 systemd.log_levelÞbug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0 2. $ sudo update-grub2 3. démarrage du système avec ce « menuentry » de débogage. 4. création du fichier : /usr/lib/systemd/system-shutdown/debug.sh (-rwxr-xr-x 1 root root) #!/bin/sh mount -o remount,rw / dmesg > /shutdown-log.txt mount -o remount,ro / 5. redémarrage du système sur le « menuentry » principal. 6. Choux blanc : pas de /shutdown-log.txt ?! Le tout sur une Sid à jour (systemd 232-18).
Bonsoir,
/sbin/shutdown est un lien vers /bin/systemctl,
man systemctl
vers la fin on trouve desméthodes d'arret
personnellement, je devrais attendre 15'
j'ai contourné le pb avec reboot
dés l'extintion du clavier, power off de l'ordinateur
essayer: trace shutdown et le bon paramètre
avant de rebooter, gdb bt
ou mise oeuvre de kdump
je n'utilise pas votre méthode d'analyse,
sous réserve la taille de 1M me parait juste
JB
Le lundi 27 février 2017 à 14:11 +0100, Alexandre Hoïde a écrit :
Chères colistières, chers colistiers,
Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos
entrailles, éclairant ma voie vers la résolution d'un problème qui
commence à me les briser.
Le problème initial est une délai de 1'30'' à l'extinction
[poweroff|reboot] du système, avec les messages systemd :
[***] A stop job is running for ifup for enp4s0 …
[***] A stop job is running for Raise network interfaces …
Bien entendu, dans un premier temps, j'ai écumé le WEB et essayé
les suggestions glanées, mais aucune n'a résolu le problème.
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode :
https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
à la section « Shutdown Completes Eventually ». Las, au démarrage
suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que
me
voilà à vous demander votre aide pour déboguer mon débogage.
Pour préciser -- les instructions du lien ci-dessus n'étant pas
très
détaillées -- j'ai procédé ainsi :
1. Ajout d'un « menuentry » dans « /etc/grub.d/40_custom », identique
au
menuentry principal généré automatiquement par Debian, à l'exception
de :
linux /boot/vmlinuz-4.9.0-2-amd64 root=UUIDcab1ac-
8020-4069-97ae-f567329ad900 systemd.log_levelÞbug
systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0
2. $ sudo update-grub2
3. démarrage du système avec ce « menuentry » de débogage.
4. création du fichier :
/usr/lib/systemd/system-shutdown/debug.sh (-rwxr-xr-x 1 root root)
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
5. redémarrage du système sur le « menuentry » principal.
6. Choux blanc : pas de /shutdown-log.txt ?!
Bonsoir, /sbin/shutdown est un lien vers /bin/systemctl, man systemctl vers la fin on trouve desméthodes d'arret personnellement, je devrais attendre 15' j'ai contourné le pb avec reboot dés l'extintion du clavier, power off de l'ordinateur essayer: trace shutdown et le bon paramètre avant de rebooter, gdb bt ou mise oeuvre de kdump je n'utilise pas votre méthode d'analyse, sous réserve la taille de 1M me parait juste JB Le lundi 27 février 2017 à 14:11 +0100, Alexandre Hoïde a écrit :
Chères colistières, chers colistiers, Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos entrailles, éclairant ma voie vers la résolution d'un problème qui commence à me les briser. Le problème initial est une délai de 1'30'' à l'extinction [poweroff|reboot] du système, avec les messages systemd : [***] A stop job is running for ifup for enp4s0 … [***] A stop job is running for Raise network interfaces … Bien entendu, dans un premier temps, j'ai écumé le WEB et essayé les suggestions glanées, mais aucune n'a résolu le problème. Afin d'en comprendre la cause, j'essaie d'appliquer la méthode : https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 à la section « Shutdown Completes Eventually ». Las, au démarrage suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me voilà à vous demander votre aide pour déboguer mon débogage. Pour préciser -- les instructions du lien ci-dessus n'étant pas très détaillées -- j'ai procédé ainsi : 1. Ajout d'un « menuentry » dans « /etc/grub.d/40_custom », identique au menuentry principal généré automatiquement par Debian, à l'exception de : linux /boot/vmlinuz-4.9.0-2-amd64 root=UUIDcab1ac- 8020-4069-97ae-f567329ad900 systemd.log_levelÞbug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0 2. $ sudo update-grub2 3. démarrage du système avec ce « menuentry » de débogage. 4. création du fichier : /usr/lib/systemd/system-shutdown/debug.sh (-rwxr-xr-x 1 root root) #!/bin/sh mount -o remount,rw / dmesg > /shutdown-log.txt mount -o remount,ro / 5. redémarrage du système sur le « menuentry » principal. 6. Choux blanc : pas de /shutdown-log.txt ?! Le tout sur une Sid à jour (systemd 232-18).
Alexandre Hoïde
On Mon, Feb 27, 2017 at 05:25:41PM +0100, maderios wrote:
On 02/27/2017 02:11 PM, Alexandre Hoïde wrote:
Chères colistières, chers colistiers, Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos entrailles, éclairant ma voie vers la résolution d'un problème qui commence à me les briser. Le problème initial est une délai de 1'30'' à l'extinction [poweroff|reboot] du système, avec les messages systemd : [***] A stop job is running for ifup for enp4s0 … [***] A stop job is running for Raise network interfaces …
Bonjour Ce problème a été réglé par des utilisateurs en changeant de noyau. Tu peux essayer de booter sur un noyau Stretch Sid sera toujours Sid... :)
Salut Madeiros et merci pour ta réponse, Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de longs mois, avec ses nombreuses versions du noyau, de systemd et de tout ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et 4.9.0-2 sur Sid). Et à ce propos, sur ce même PC, j'ai une Stretch à jour qui ne pose pas ce problème de délai à l'extinction, avec une configuration réseau identique : ifupdown et interfaces déclarées de la même manière dans /etc/network/interfaces[.d/] + Network-Manager installé/activé mais que je n'utilise ni pour configurer ni pour changer d'interface (ethernet/wifi). Je prendrais volontiers toute autre suggestion pour régler le problème initial, bien que la question qui me taraude, dans l'immédiat, est de savoir pourquoi la procédure de debug proposée par freedesktop.org ne fonctionne pas. -- ___________________ _________________ | $ post_tenebras ↲ | waouh! ?! | $ per_systemd ↲ | | GNU / | / | TENEBRAS : | | -- * -- | o <O> | #)&&*+^'.|;>%9- | | $ who ↲ / |_-- ~_| | | =!¨!$£{]]_:`¢_´ | | Alexandre Hoïde | _/| | / | … … … ...---... | ------------------- -----------------
On Mon, Feb 27, 2017 at 05:25:41PM +0100, maderios wrote:
On 02/27/2017 02:11 PM, Alexandre Hoïde wrote:
> Chères colistières, chers colistiers,
>
> Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos
> entrailles, éclairant ma voie vers la résolution d'un problème qui
> commence à me les briser.
> Le problème initial est une délai de 1'30'' à l'extinction
> [poweroff|reboot] du système, avec les messages systemd :
> [***] A stop job is running for ifup for enp4s0 …
> [***] A stop job is running for Raise network interfaces …
Bonjour
Ce problème a été réglé par des utilisateurs en changeant de noyau.
Tu peux essayer de booter sur un noyau Stretch
Sid sera toujours Sid... :)
Salut Madeiros et merci pour ta réponse,
Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de
longs mois, avec ses nombreuses versions du noyau, de systemd et de tout
ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et
4.9.0-2 sur Sid).
Et à ce propos, sur ce même PC, j'ai une Stretch à jour qui ne pose
pas ce problème de délai à l'extinction, avec une configuration réseau
identique : ifupdown et interfaces déclarées de la même manière dans
/etc/network/interfaces[.d/] + Network-Manager installé/activé mais
que je n'utilise ni pour configurer ni pour changer d'interface
(ethernet/wifi).
Je prendrais volontiers toute autre suggestion pour régler le problème
initial, bien que la question qui me taraude, dans l'immédiat, est de
savoir pourquoi la procédure de debug proposée par freedesktop.org ne
fonctionne pas.
On Mon, Feb 27, 2017 at 05:25:41PM +0100, maderios wrote:
On 02/27/2017 02:11 PM, Alexandre Hoïde wrote:
Chères colistières, chers colistiers, Je me tourne vers vous dans l'espoir qu'une lumière jaillira de vos entrailles, éclairant ma voie vers la résolution d'un problème qui commence à me les briser. Le problème initial est une délai de 1'30'' à l'extinction [poweroff|reboot] du système, avec les messages systemd : [***] A stop job is running for ifup for enp4s0 … [***] A stop job is running for Raise network interfaces …
Bonjour Ce problème a été réglé par des utilisateurs en changeant de noyau. Tu peux essayer de booter sur un noyau Stretch Sid sera toujours Sid... :)
Salut Madeiros et merci pour ta réponse, Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de longs mois, avec ses nombreuses versions du noyau, de systemd et de tout ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et 4.9.0-2 sur Sid). Et à ce propos, sur ce même PC, j'ai une Stretch à jour qui ne pose pas ce problème de délai à l'extinction, avec une configuration réseau identique : ifupdown et interfaces déclarées de la même manière dans /etc/network/interfaces[.d/] + Network-Manager installé/activé mais que je n'utilise ni pour configurer ni pour changer d'interface (ethernet/wifi). Je prendrais volontiers toute autre suggestion pour régler le problème initial, bien que la question qui me taraude, dans l'immédiat, est de savoir pourquoi la procédure de debug proposée par freedesktop.org ne fonctionne pas. -- ___________________ _________________ | $ post_tenebras ↲ | waouh! ?! | $ per_systemd ↲ | | GNU / | / | TENEBRAS : | | -- * -- | o <O> | #)&&*+^'.|;>%9- | | $ who ↲ / |_-- ~_| | | =!¨!$£{]]_:`¢_´ | | Alexandre Hoïde | _/| | / | … … … ...---... | ------------------- -----------------
Alexandre Hoïde
On Mon, Feb 27, 2017 at 05:54:54PM +0100, JB wrote:
Bonsoir,
Bonsoir JB et merci pour ta réponse,
/sbin/shutdown est un lien vers /bin/systemctl, man systemctl
Oui, et d'ailleurs j'utilise : $ systemctl poweroff|reboot
vers la fin on trouve desméthodes d'arret personnellement, je devrais attendre 15' j'ai contourné le pb avec reboot dés l'extintion du clavier, power off de l'ordinateur
De mon côté, si je veux contourner le problème, j'utilise : $ sudo poweroff|reboot -f ou encore : $ sudo systemctl disable NetworkManager-wait-online.service
essayer: trace shutdown et le bon paramètre avant de rebooter, gdb bt ou mise oeuvre de kdump
Il me semble que pour utiliser un de ces outils (et comprendre un peu ce qu'on fait), il faut manger pas mal de docs. Je ne suis pas hyper motivé, sachant que je n'en aurais pas beaucoup l'usage.
je n'utilise pas votre méthode d'analyse, sous réserve la taille de 1M me parait juste
C'est déjà ça ! ^^ … toujours preneur pour un débogage de la méthode de débogage de freedesktop.org, donc :)
On Mon, Feb 27, 2017 at 05:54:54PM +0100, JB wrote:
Bonsoir,
Bonsoir JB et merci pour ta réponse,
/sbin/shutdown est un lien vers /bin/systemctl,
man systemctl
Oui, et d'ailleurs j'utilise :
$ systemctl poweroff|reboot
vers la fin on trouve desméthodes d'arret
personnellement, je devrais attendre 15'
j'ai contourné le pb avec reboot
dés l'extintion du clavier, power off de l'ordinateur
De mon côté, si je veux contourner le problème, j'utilise :
$ sudo poweroff|reboot -f
ou encore :
$ sudo systemctl disable NetworkManager-wait-online.service
essayer: trace shutdown et le bon paramètre
avant de rebooter, gdb bt
ou mise oeuvre de kdump
Il me semble que pour utiliser un de ces outils (et comprendre un peu
ce qu'on fait), il faut manger pas mal de docs. Je ne suis pas hyper
motivé, sachant que je n'en aurais pas beaucoup l'usage.
je n'utilise pas votre méthode d'analyse,
sous réserve la taille de 1M me parait juste
C'est déjà ça ! ^^
… toujours preneur pour un débogage de la méthode de débogage de
freedesktop.org, donc :)
On Mon, Feb 27, 2017 at 05:54:54PM +0100, JB wrote:
Bonsoir,
Bonsoir JB et merci pour ta réponse,
/sbin/shutdown est un lien vers /bin/systemctl, man systemctl
Oui, et d'ailleurs j'utilise : $ systemctl poweroff|reboot
vers la fin on trouve desméthodes d'arret personnellement, je devrais attendre 15' j'ai contourné le pb avec reboot dés l'extintion du clavier, power off de l'ordinateur
De mon côté, si je veux contourner le problème, j'utilise : $ sudo poweroff|reboot -f ou encore : $ sudo systemctl disable NetworkManager-wait-online.service
essayer: trace shutdown et le bon paramètre avant de rebooter, gdb bt ou mise oeuvre de kdump
Il me semble que pour utiliser un de ces outils (et comprendre un peu ce qu'on fait), il faut manger pas mal de docs. Je ne suis pas hyper motivé, sachant que je n'en aurais pas beaucoup l'usage.
je n'utilise pas votre méthode d'analyse, sous réserve la taille de 1M me parait juste
C'est déjà ça ! ^^ … toujours preneur pour un débogage de la méthode de débogage de freedesktop.org, donc :)
Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de longs mois, avec ses nombreuses versions du noyau, de systemd et de tout ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et 4.9.0-2 sur Sid).
Tu pourrais peut-être envoyer un rapport de bug. -- Maderios
On 02/27/2017 09:35 PM, Alexandre Hoïde wrote:
Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de
longs mois, avec ses nombreuses versions du noyau, de systemd et de tout
ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et
4.9.0-2 sur Sid).
Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de longs mois, avec ses nombreuses versions du noyau, de systemd et de tout ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et 4.9.0-2 sur Sid).
Tu pourrais peut-être envoyer un rapport de bug. -- Maderios
Alexandre Hoïde
On Tue, Feb 28, 2017 at 09:37:10AM +0100, maderios wrote:
On 02/27/2017 09:35 PM, Alexandre Hoïde wrote:
Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de longs mois, avec ses nombreuses versions du noyau, de systemd et de tout ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et 4.9.0-2 sur Sid).
Tu pourrais peut-être envoyer un rapport de bug.
Mais, j'envisage très sérieusement cette option ! J'aimerais tout de même creuser un peu avant d'envoyer… ne serait-ce que pour savoir à quel paquet il faudrait attribuer le rapport. Et puis, la primo-installation de ma Sid remontant à plusieurs années, il est fort probable que j'aie négligé moult messages de changelogs… encore une fois, sur une Stretch fraîchement installée (avec beaucoup moins de logiciels installés), le problème ne se pose pas. C'est une occasion de me familiariser un peu plus avec systemd -- en dépit de mon aversion. ^^ -- ___________________ _________________ | $ post_tenebras ↲ | waouh! ?! | $ per_systemd ↲ | | GNU / | / | TENEBRAS : | | -- * -- | o <O> | #)&&*+^'.|;>%9- | | $ who ↲ / |_-- ~_| | | =!¨!$£{]]_:`¢_´ | | Alexandre Hoïde | _/| | / | … … … ...---... | ------------------- -----------------
On Tue, Feb 28, 2017 at 09:37:10AM +0100, maderios wrote:
On 02/27/2017 09:35 PM, Alexandre Hoïde wrote:
> Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de
> longs mois, avec ses nombreuses versions du noyau, de systemd et de tout
> ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et
> 4.9.0-2 sur Sid).
Tu pourrais peut-être envoyer un rapport de bug.
Mais, j'envisage très sérieusement cette option ! J'aimerais tout de
même creuser un peu avant d'envoyer… ne serait-ce que pour savoir à quel
paquet il faudrait attribuer le rapport. Et puis, la primo-installation
de ma Sid remontant à plusieurs années, il est fort probable que j'aie
négligé moult messages de changelogs… encore une fois, sur une Stretch
fraîchement installée (avec beaucoup moins de logiciels installés), le
problème ne se pose pas.
C'est une occasion de me familiariser un peu plus avec systemd -- en
dépit de mon aversion. ^^
On Tue, Feb 28, 2017 at 09:37:10AM +0100, maderios wrote:
On 02/27/2017 09:35 PM, Alexandre Hoïde wrote:
Malheureusement, sur ma Sid, le délai à l'extinction résiste depuis de longs mois, avec ses nombreuses versions du noyau, de systemd et de tout ce qui va avec… y compris le noyau 4.9.0-1 (actuellement sur Stretch et 4.9.0-2 sur Sid).
Tu pourrais peut-être envoyer un rapport de bug.
Mais, j'envisage très sérieusement cette option ! J'aimerais tout de même creuser un peu avant d'envoyer… ne serait-ce que pour savoir à quel paquet il faudrait attribuer le rapport. Et puis, la primo-installation de ma Sid remontant à plusieurs années, il est fort probable que j'aie négligé moult messages de changelogs… encore une fois, sur une Stretch fraîchement installée (avec beaucoup moins de logiciels installés), le problème ne se pose pas. C'est une occasion de me familiariser un peu plus avec systemd -- en dépit de mon aversion. ^^ -- ___________________ _________________ | $ post_tenebras ↲ | waouh! ?! | $ per_systemd ↲ | | GNU / | / | TENEBRAS : | | -- * -- | o <O> | #)&&*+^'.|;>%9- | | $ who ↲ / |_-- ~_| | | =!¨!$£{]]_:`¢_´ | | Alexandre Hoïde | _/| | / | … … … ...---... | ------------------- -----------------
S
Bonjour, Le lundi 27 février 2017 à 14:11, Alexandre Hoïde a écrit :
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode : https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 à la section « Shutdown Completes Eventually ». Las, au démarrage suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me voilà à vous demander votre aide pour déboguer mon débogage.
J’ai déjà appliqué cette méthode avec succès (d’ailleurs ton message m’a permis de voir qu’il me restait des fichiers de log à la racine de mon disque, merci). Si je compare ce que dit la doc et ce que j’avais écrit dans mon journal à ce sujet, je constate une différence de chemin. J’avais mis mon script dans « /lib/systemd/system-shutdown/debug.sh ». (Je crois me souvenir qu’il y a une subtilité dans les chemins avec Systemd sous Debian). Sébastien
Bonjour,
Le lundi 27 février 2017 à 14:11, Alexandre Hoïde a écrit :
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode :
https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
à la section « Shutdown Completes Eventually ». Las, au démarrage
suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me
voilà à vous demander votre aide pour déboguer mon débogage.
J’ai déjà appliqué cette méthode avec succès (d’ailleurs ton message m’a permis
de voir qu’il me restait des fichiers de log à la racine de mon disque, merci).
Si je compare ce que dit la doc et ce que j’avais écrit dans mon journal à ce
sujet, je constate une différence de chemin. J’avais mis mon script dans
« /lib/systemd/system-shutdown/debug.sh ».
(Je crois me souvenir qu’il y a une subtilité dans les chemins avec Systemd sous
Debian).
Bonjour, Le lundi 27 février 2017 à 14:11, Alexandre Hoïde a écrit :
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode : https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 à la section « Shutdown Completes Eventually ». Las, au démarrage suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me voilà à vous demander votre aide pour déboguer mon débogage.
J’ai déjà appliqué cette méthode avec succès (d’ailleurs ton message m’a permis de voir qu’il me restait des fichiers de log à la racine de mon disque, merci). Si je compare ce que dit la doc et ce que j’avais écrit dans mon journal à ce sujet, je constate une différence de chemin. J’avais mis mon script dans « /lib/systemd/system-shutdown/debug.sh ». (Je crois me souvenir qu’il y a une subtilité dans les chemins avec Systemd sous Debian). Sébastien
Alexandre Hoïde
On Thu, Mar 02, 2017 at 02:01:46PM +0100, Sébastien NOBILI wrote:
Bonjour,
Bonjour Sébastien et merci pour ta réponse,
Le lundi 27 février 2017 à 14:11, Alexandre Hoïde a écrit :
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode : https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 à la section « Shutdown Completes Eventually ». Las, au démarrage suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me voilà à vous demander votre aide pour déboguer mon débogage.
J’ai déjà appliqué cette méthode avec succès (d’ailleurs ton message m’a permis de voir qu’il me restait des fichiers de log à la racine de mon disque, merci).
(Avec plaisir !)
Si je compare ce que dit la doc et ce que j’avais écrit dans mon journal à ce sujet, je constate une différence de chemin. J’avais mis mon script dans « /lib/systemd/system-shutdown/debug.sh ». (Je crois me souvenir qu’il y a une subtilité dans les chemins avec Systemd sous Debian).
Bim badaboum! C'était bien là la cause de mon problème. Merci encore ! Je ferme en [résolu] et je ferai un autre fil pour informer des suites du problème initial… dès que j'aurai le temps de lire ce /shutdown-log.txt tout frais ! Meilleures salutations, -- ___________________ _________________ | $ post_tenebras ↲ | waouh! ?! | $ per_systemd ↲ | | GNU / | / | TENEBRAS : | | -- * -- | o <O> | #)&&*+^'.|;>%9- | | $ who ↲ / |_-- ~_| | | =!¨!$£{]]_:`¢_´ | | Alexandre Hoïde | _/| | / | … … … ...---... | ------------------- -----------------
On Thu, Mar 02, 2017 at 02:01:46PM +0100, Sébastien NOBILI wrote:
Bonjour,
Bonjour Sébastien et merci pour ta réponse,
Le lundi 27 février 2017 à 14:11, Alexandre Hoïde a écrit :
> Afin d'en comprendre la cause, j'essaie d'appliquer la méthode :
> https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
> à la section « Shutdown Completes Eventually ». Las, au démarrage
> suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me
> voilà à vous demander votre aide pour déboguer mon débogage.
J’ai déjà appliqué cette méthode avec succès (d’ailleurs ton message m’a permis
de voir qu’il me restait des fichiers de log à la racine de mon disque, merci).
(Avec plaisir !)
Si je compare ce que dit la doc et ce que j’avais écrit dans mon journal à ce
sujet, je constate une différence de chemin. J’avais mis mon script dans
« /lib/systemd/system-shutdown/debug.sh ».
(Je crois me souvenir qu’il y a une subtilité dans les chemins avec Systemd sous
Debian).
Bim badaboum! C'était bien là la cause de mon problème. Merci encore !
Je ferme en [résolu] et je ferai un autre fil pour informer des suites
du problème initial… dès que j'aurai le temps de lire ce
/shutdown-log.txt tout frais !
On Thu, Mar 02, 2017 at 02:01:46PM +0100, Sébastien NOBILI wrote:
Bonjour,
Bonjour Sébastien et merci pour ta réponse,
Le lundi 27 février 2017 à 14:11, Alexandre Hoïde a écrit :
Afin d'en comprendre la cause, j'essaie d'appliquer la méthode : https://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 à la section « Shutdown Completes Eventually ». Las, au démarrage suivant, le fichier « /shutdown-log.txt » n'existe pas. Si bien que me voilà à vous demander votre aide pour déboguer mon débogage.
J’ai déjà appliqué cette méthode avec succès (d’ailleurs ton message m’a permis de voir qu’il me restait des fichiers de log à la racine de mon disque, merci).
(Avec plaisir !)
Si je compare ce que dit la doc et ce que j’avais écrit dans mon journal à ce sujet, je constate une différence de chemin. J’avais mis mon script dans « /lib/systemd/system-shutdown/debug.sh ». (Je crois me souvenir qu’il y a une subtilité dans les chemins avec Systemd sous Debian).
Bim badaboum! C'était bien là la cause de mon problème. Merci encore ! Je ferme en [résolu] et je ferai un autre fil pour informer des suites du problème initial… dès que j'aurai le temps de lire ce /shutdown-log.txt tout frais ! Meilleures salutations, -- ___________________ _________________ | $ post_tenebras ↲ | waouh! ?! | $ per_systemd ↲ | | GNU / | / | TENEBRAS : | | -- * -- | o <O> | #)&&*+^'.|;>%9- | | $ who ↲ / |_-- ~_| | | =!¨!$£{]]_:`¢_´ | | Alexandre Hoïde | _/| | / | … … … ...---... | ------------------- -----------------
