[KDE] Extinction du PC longue (résolu)

Applications, problèmes de configuration réseau
Répondre
Sirilldu
archer
Messages : 146
Inscription : mer. 27 mars 2013, 19:45

[KDE] Extinction du PC longue (résolu)

Message par Sirilldu »

Bonjour,

Depuis plusieurs jours, le PC met du temps à s'éteindre.
Visiblement c'est à cause de dm-crypt qui n'arrive pas à démonter les partitions chiffrées.
Un bout de journalctl :

Code : Tout sélectionner

mars 01 11:52:29 cyrarch systemd[1]: Timed out stoppping /sys/devices/virtual/block/dm-6.
mars 01 11:52:29 cyrarch systemd[1]: sys-devices-virtual-block-dm\x2d6.device: Job sys-devices-virtual-block-dm\x2d6.device/stop failed with result 'timeout'.
mars 01 11:52:29 cyrarch systemd[1]: dev-dm\x2d6.device: Job dev-dm\x2d6.device/stop timed out.
mars 01 11:52:29 cyrarch systemd[1]: Timed out stoppping /dev/dm-6.
mars 01 11:52:29 cyrarch systemd[1]: dev-dm\x2d6.device: Job dev-dm\x2d6.device/stop failed with result 'timeout'.
mars 01 11:52:29 cyrarch systemd[1]: sys-devices-virtual-block-dm\x2d3.device: Job sys-devices-virtual-block-dm\x2d3.device/stop timed out.
mars 01 11:52:29 cyrarch systemd[1]: Timed out stoppping /sys/devices/virtual/block/dm-3.
mars 01 11:52:29 cyrarch systemd[1]: sys-devices-virtual-block-dm\x2d3.device: Job sys-devices-virtual-block-dm\x2d3.device/stop failed with result 'timeout'.
mars 01 11:52:29 cyrarch systemd[1]: sys-devices-virtual-block-dm\x2d1.device: Job sys-devices-virtual-block-dm\x2d1.device/stop timed out.
mars 01 11:52:29 cyrarch systemd[1]: Timed out stoppping /sys/devices/virtual/block/dm-1.
mars 01 11:52:29 cyrarch systemd[1]: sys-devices-virtual-block-dm\x2d1.device: Job sys-devices-virtual-block-dm\x2d1.device/stop failed with result 'timeout'.
mars 01 11:52:29 cyrarch systemd[1]: dev-dm\x2d2.device: Job dev-dm\x2d2.device/stop timed out.
mars 01 11:52:29 cyrarch systemd[1]: Timed out stoppping /dev/dm-2.
mars 01 11:52:29 cyrarch systemd[1]: dev-dm\x2d2.device: Job dev-dm\x2d2.device/stop failed with result 'timeout'.
Auriez-vous aussi rencontré ce problème ?
Dernière modification par Sirilldu le mar. 01 mars 2016, 15:46, modifié 1 fois.
Arch 64 | KDE
Moviuro
Elfe
Messages : 765
Inscription : dim. 17 juin 2012, 22:49

Re: [dm-crypt] Extinction du PC longue

Message par Moviuro »

Plop,

Pour être tout à fait honnête, je n'ai pas redémarré ma machine depuis ~15 jours, mais j'ai pas souvenir de ce genre de soucis.
Tu peux donner les versions des paquets concernés ? (systemd, cryptsetup, mkinitcpio, etc.) Et le contenu de ton fstab et crypttab ?

Comment tu montes tes partitions chiffrées au démarrage ? (crypttab.initramfs ? crypttab ?...)
psycho : Latitude E6430 ; BTRFS over LUKS, UEFI & secureboot
schizo : Acer 8942G ; KDE 4, BTRFS over LUKS ; W7 (prend la poussière)
toxo : i5-6600K, bspwm, VM W10 en PCI-passthrough
deadman : Lenovo Thinkcenter, OpenBSD 6.0-stable
popho.be : Kimsufi KS-3, FreeBSD 11.0
Loi de Murphy : Le jour où tu as besoin d'une backup, tu te dis que tu aurais dû en mettre en place
Venez sur IRC en plus du forum !
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17285
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [dm-crypt] Extinction du PC longue

Message par benjarobin »

Bonjour,
Quelle version de systemd ? Si c'est la version 229 c'est sûrement lié à un des 2 problèmes connus (coredump lors de l'extinction, et timeout de 90s lors de l'extinction...)
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Moviuro
Elfe
Messages : 765
Inscription : dim. 17 juin 2012, 22:49

Re: [dm-crypt] Extinction du PC longue

Message par Moviuro »

benjarobin a écrit :(coredump lors de l'extinction, et timeout de 90s lors de l'extinction...)
De vrai ? on pourrait avoir un lien stp ? Parce que là, ça dépasse vraiment tous les niveaux d'amateurisme. Franchement...
psycho : Latitude E6430 ; BTRFS over LUKS, UEFI & secureboot
schizo : Acer 8942G ; KDE 4, BTRFS over LUKS ; W7 (prend la poussière)
toxo : i5-6600K, bspwm, VM W10 en PCI-passthrough
deadman : Lenovo Thinkcenter, OpenBSD 6.0-stable
popho.be : Kimsufi KS-3, FreeBSD 11.0
Loi de Murphy : Le jour où tu as besoin d'une backup, tu te dis que tu aurais dû en mettre en place
Venez sur IRC en plus du forum !
Sirilldu
archer
Messages : 146
Inscription : mer. 27 mars 2013, 19:45

Re: [dm-crypt] Extinction du PC longue

Message par Sirilldu »

Effectivement je suis en version 229 pour systemd et cette ligne dans journalctl :

Code : Tout sélectionner

mars 01 11:51:00 cyrarch systemd-coredump[5065]: Failed to connect to coredump service: Connection refused
Arch 64 | KDE
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17285
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [dm-crypt] Extinction du PC longue

Message par benjarobin »

Moviuro a écrit :De vrai ? on pourrait avoir un lien stp ? Parce que là, ça dépasse vraiment tous les niveaux d'amateurisme. Franchement...
Amateurisme, c'est bien un non développeur qui parle là ? Non je ne pense pas... Pour le coredump, si tu as un programme qui crash lors de l'extinction du PC ce n'est pas la faute de systemd, cela à pour conséquence l'enregistrement d'un coredump. Hors si le disque dur comme le processeur est assez lent cela peut arriver à déclencher des timeout lors de l'extinction du PC. Ceci est arrivé suite au changement de la logique de la gestion des coredump par systemd, mais ce n'est absolument pas systemd qui est coupable ici, il met juste en évidence des problèmes. Après oui on pourrait améliorer l’expérience utilisateur, et ce sera surement fait pour que ce cas là soit bien mieux géré...

https://github.com/systemd/systemd/issues/2691
https://github.com/systemd/systemd/issues/1615
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Moviuro
Elfe
Messages : 765
Inscription : dim. 17 juin 2012, 22:49

Re: [dm-crypt] Extinction du PC longue

Message par Moviuro »

benjarobin a écrit :
Moviuro a écrit :De vrai ? on pourrait avoir un lien stp ? Parce que là, ça dépasse vraiment tous les niveaux d'amateurisme. Franchement...
Amateurisme, c'est bien un non développeur qui parle là ?
Mauvaise compréhension : j'avais compris que c'était systemd qui core-dumpait.
psycho : Latitude E6430 ; BTRFS over LUKS, UEFI & secureboot
schizo : Acer 8942G ; KDE 4, BTRFS over LUKS ; W7 (prend la poussière)
toxo : i5-6600K, bspwm, VM W10 en PCI-passthrough
deadman : Lenovo Thinkcenter, OpenBSD 6.0-stable
popho.be : Kimsufi KS-3, FreeBSD 11.0
Loi de Murphy : Le jour où tu as besoin d'une backup, tu te dis que tu aurais dû en mettre en place
Venez sur IRC en plus du forum !
Sirilldu
archer
Messages : 146
Inscription : mer. 27 mars 2013, 19:45

Re: [dm-crypt] Extinction du PC longue

Message par Sirilldu »

Si je fais une déconnexion, puis éteindre depuis sddm, alors je n'ai pas le timeout de 90s.

Et à ce moment la, après avoir redémarrer, je trouve le coredump dans journalctl :

Code : Tout sélectionner

mars 01 14:17:14 cyrarch sddm-helper[884]: [PAM] Ended.
mars 01 14:17:14 cyrarch sddm[770]: Auth: sddm-helper exited successfully
mars 01 14:17:14 cyrarch sddm[770]: Socket server stopping...
mars 01 14:17:14 cyrarch sddm[770]: Socket server stopped.
mars 01 14:17:14 cyrarch sddm[770]: Display server stopping...
mars 01 14:17:14 cyrarch kernel: kactivitymanage[1058]: segfault at 7f1e44076cd0 ip 00007f1e44017291 sp 00007ffc7fb89a38 error 4 in libQt5Sql.so.5.5.1[7f1e44003000+3f000]
mars 01 14:17:14 cyrarch systemd[1]: Created slice system-systemd\x2dcoredump.slice.
mars 01 14:17:14 cyrarch systemd[1]: Started Process Core Dump (PID 1410/UID 0).
mars 01 14:17:14 cyrarch systemd-coredump[1411]: Process 1058 (kactivitymanage) of user 1000 dumped core.
                                                 
                                                 Stack trace of thread 1058:
                                                 #0  0x00007f1e44017291 _ZN12QSqlDatabase5closeEv (libQt5Sql.so.5)
                                                 #1  0x00007f1e440187f9 _ZN12QSqlDatabaseD1Ev (libQt5Sql.so.5)
                                                 #2  0x00007f1e4401a82d n/a (libQt5Sql.so.5)
                                                 #3  0x00007f1e528a8299 _ZN9QHashData11free_helperEPFvPNS_4NodeEE (libQt5Core.so.5)
                                                 #4  0x00007f1e44016f63 n/a (libQt5Sql.so.5)
                                                 #5  0x00007f1e520b1c38 __run_exit_handlers (libc.so.6)
                                                 #6  0x00007f1e520b1c85 exit (libc.so.6)
                                                 #7  0x00007f1e48d3de4e _ZN14QXcbConnection16processXcbEventsEv (libQt5XcbQpa.so.5)
                                                 #8  0x00007f1e52a551e1 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5)
                                                 #9  0x00007f1e532d09ac _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5)
                                                 #10 0x00007f1e532d5e86 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5)
                                                 #11 0x00007f1e52a25bab _ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent (libQt5Core.so.5)
                                                 #12 0x00007f1e52a27fa6 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5)
                                                 #13 0x00007f1e52a7c143 n/a (libQt5Core.so.5)
                                                 #14 0x00007f1e50c97d87 g_main_context_dispatch (libglib-2.0.so.0)
                                                 #15 0x00007f1e50c97fe0 n/a (libglib-2.0.so.0)
                                                 #16 0x00007f1e50c9808c g_main_context_iteration (libglib-2.0.so.0)
                                                 #17 0x00007f1e52a7c54f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #18 0x00007f1e52a2357a _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #19 0x00007f1e52a2b53c _ZN16QCoreApplication4execEv (libQt5Core.so.5)
                                                 #20 0x0000000000410aa4 main (kactivitymanagerd)
                                                 #21 0x00007f1e5209c710 __libc_start_main (libc.so.6)
                                                 #22 0x0000000000410c79 _start (kactivitymanagerd)
                                                 
                                                 Stack trace of thread 1071:
                                                 #0  0x00007f1e5215ac3d poll (libc.so.6)
                                                 #1  0x00007f1e50c97f7c n/a (libglib-2.0.so.0)
                                                 #2  0x00007f1e50c9808c g_main_context_iteration (libglib-2.0.so.0)
                                                 #3  0x00007f1e52a7c56b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #4  0x00007f1e52a2357a _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #5  0x00007f1e5283fbe4 _ZN7QThread4execEv (libQt5Core.so.5)
                                                 #6  0x0000000000412e0a _ZZ12runInQThreadI8FeaturesEPT_vEN6Thread3runEv (kactivitymanagerd)
                                                 #7  0x00007f1e52844b8e n/a (libQt5Core.so.5)
                                                 #8  0x00007f1e511b5424 start_thread (libpthread.so.0)
                                                 #9  0x00007f1e52163cbd __clone (libc.so.6)
                                                 
                                                 Stack trace of thread 1069:
                                                 #0  0x00007f1e5215ac3d poll (libc.so.6)
                                                 #1  0x00007f1e50c97f7c n/a (libglib-2.0.so.0)
                                                 #2  0x00007f1e50c9808c g_main_context_iteration (libglib-2.0.so.0)
                                                 #3  0x00007f1e52a7c54f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #4  0x00007f1e52a2357a _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #5  0x00007f1e5283fbe4 _ZN7QThread4execEv (libQt5Core.so.5)
                                                 #6  0x0000000000412daa _ZZ12runInQThreadI9ResourcesEPT_vEN6Thread3runEv (kactivitymanagerd)
                                                 #7  0x00007f1e52844b8e n/a (libQt5Core.so.5)
                                                 #8  0x00007f1e511b5424 start_thread (libpthread.so.0)
                                                 #9  0x00007f1e52163cbd __clone (libc.so.6)
                                                 
                                                 Stack trace of thread 1070:
                                                 #0  0x00007f1e5215ac3d poll (libc.so.6)
                                                 #1  0x00007f1e50c97f7c n/a (libglib-2.0.so.0)
                                                 #2  0x00007f1e50c9808c g_main_context_iteration (libglib-2.0.so.0)
                                                 #3  0x00007f1e52a7c54f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #4  0x00007f1e52a2357a _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                 #5  0x00007f1e5283fbe4 _ZN7QThread4execEv (libQt5Core.so.5)
                                                 #6  0x0000000000412dda _ZZ12runInQThreadI10ActivitiesEPT_vEN6Thread3runEv (kactivitymanagerd)
                                                 #7  0x00007f1e52844b8e n/a (libQt5Core.so.5)
                                                 #8  0x00007f1e511b5424 start_thread (libpthread.so.0)
                                                 #9  0x00007f1e52163cbd __clone (libc.so.6)
                                                 
                                                 Stack trace of thread 1223:
                                                 #0  0x00007f1e5213361d __nanosleep (libc.so.6)
                                                 #1  0x00007f1e528f52cd n/a (libQt5Core.so.5)
                                                 #2  0x00007f1e52843f4b _ZN7QThread5sleepEm (libQt5Core.so.5)
                                                 #3  0x00007f1e38da877e n/a (kactivitymanagerd_plugin_sqlite.so)
                                                 #4  0x00007f1e52844b8e n/a (libQt5Core.so.5)
                                                 #5  0x00007f1e511b5424 start_thread (libpthread.so.0)
                                                 #6  0x00007f1e52163cbd __clone (libc.so.6)
mars 01 14:17:14 cyrarch sddm[770]: Display server stopped.
mars 01 14:17:14 cyrarch sddm[770]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
mars 01 14:17:14 cyrarch sddm[770]: Removing display ":0" ...
mars 01 14:17:14 cyrarch sddm[770]: Adding new display on vt 1 ...
mars 01 14:17:14 cyrarch sddm[770]: Display server starting...
mars 01 14:17:14 cyrarch sddm[770]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{cf24c00a-dbcd-4eb1-b83b-3ec175516968} -background none -noreset -displayfd 18 vt1
mars 01 14:17:15 cyrarch sddm[770]: Running display setup script  "/usr/share/sddm/scripts/Xsetup"
mars 01 14:17:15 cyrarch sddm[770]: Display server started.
mars 01 14:17:15 cyrarch sddm[770]: Socket server starting...
mars 01 14:17:15 cyrarch sddm[770]: Socket server started.
mars 01 14:17:15 cyrarch sddm[770]: Greeter starting...
mars 01 14:17:15 cyrarch sddm[770]: Adding cookie to "/var/run/sddm/{cf24c00a-dbcd-4eb1-b83b-3ec175516968}"
mars 01 14:17:15 cyrarch sddm-helper[1427]: [PAM] Starting...
mars 01 14:17:15 cyrarch sddm-helper[1427]: [PAM] Authenticating...
mars 01 14:17:15 cyrarch sddm-helper[1427]: [PAM] returning.
mars 01 14:17:15 cyrarch sddm-helper[1427]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Du coup, la faute ne semble pas venir de dm-crypt, je renomme la discussion ?
Arch 64 | KDE
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17285
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [dm-crypt] Extinction du PC longue

Message par benjarobin »

Non, en effet ce n'est pas du tout dm-crypte le coupable. C'est un bug dans KDE (qui crash à la fermeture), mit en évidence par systemd. Mais systemd devrait bien mieux se comporter lors d'un coredump lors d'une extinction, donc c'est quand même aussi un bug côté systemd.

Tu peux essayer de désactiver Core_dump pour voir si cela améliore les choses
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Sirilldu
archer
Messages : 146
Inscription : mer. 27 mars 2013, 19:45

Re: [dm-crypt] Extinction du PC longue

Message par Sirilldu »

J'ai désactiver Coredump par systemd et c'est nickel.

Merci.
Arch 64 | KDE
lemust83
yeomen
Messages : 206
Inscription : ven. 11 déc. 2015, 21:20

Re: [KDE] Extinction du PC longue (résolu)

Message par lemust83 »

Bonjour
J'aimerais apporter quelques remarques à ce phénomène qui semble récurent sur pas mal de distros utilisant systemd, avec divers D.E. et noyaux et ce depuis pas mal de temps si j'en crois ce que j'ai lu là dessus. J'ai sur toutes mes machines systemd 229-3 avec un kerrnel 4.4. Pas envie de rétrograder systemd.
Sur Manjaro, Xfce4.12, si une partition même non cryptée est montée dans /run/media/... et que j'éteins par le xfce4-logout-session, j'ai droit à un message du type "A stop job is running for session C2 user...." Inutile de préciser qu'avant la mise à jour récente de systemd, je n'avais rien noté d'anormal.
Même chose avec Arch Xfce sans le message d'erreur, mais avec 90 interminables secondes . Sans partition montée, pas de souci.
Curieusement, si je passe un petit sytemctl poweroff ou un simple poweroff puisque que ce sont des alias, même en laissant les partitions montées, ça s'éteint normalement....
Il y aurait il un problème de chronologie dans la méthode d'extinction ?
Tour: Arch (Xfce) 64 Testing: 6-Core: AMD Ryzen 5 2600X type: MT MCP speed: 2152 MHz min/max: 2200/3600 MH
UEFI: American Megatrends v: 3803 date: 01/22/2018
Graphics:
Device-1: AMD Baffin [Radeon RX 460/560D / Pro
450/455/460/555/555X/560/560X]
driver: amdgpu v: kernel
Display: server: X.Org 1.20.8 driver: amdgpu,ati unloaded: modesetting
resolution: 1920x1080~60Hz
OpenGL: renderer: Radeon RX 560 Series
Manjaro en Dual (grub).
Avatar de l’utilisateur
waitnsea
Maître du Kyudo
Messages : 2114
Inscription : jeu. 15 mars 2012, 05:08

Re: [KDE] Extinction du PC longue (résolu)

Message par waitnsea »

Bonjour à tous,
Je ne suis pas sur que la désactivation des Core dump par un fichier /etc/systemd/coredump.conf.d/custom.conf comme dit dans le lien du Wiki indiqué par benjarobin suffise.
Ce wiki n'est pas à jour :

Code : Tout sélectionner

Core dumps may be useful for developers to debug program crashes, however they are practically useless to the average user, and have been largely obsoleted by modern debuggers.
est en contradiction avec : (source)

Code : Tout sélectionner

    * systemd-coredump
systemd-coredump est l’outil qui gère les vidanges mémoires (core dumps), c’est‐à‐dire le contenu de la mémoire du programme avant son plantage.

Le comportement de systemd-coredump a pas mal changé : il génère dorénavant automatiquement une trace d’appel enregistrée dans le journal pour toutes les vidanges système (grâce à la bibliothèque libdw des elfutils). De plus, il enregistre maintenant les vidanges système directement sur le disque (sous /var/lib/systemd/coredump, si possible dans un format compressé), au lieu de les enregistrer dans le journal. Un nouveau fichier de configuration /etc/systemd/coredump.conf a été ajouté pour configurer les autres paramètres de systemd-coredump.

On utilise la commande coredumpctl pour consulter les informations collectées par systemd-coredump. Elle a été enrichie de deux nouvelles options : info, pour afficher les détails de la vidange système choisie, et -1, pour afficher uniquement les informations de la plus récente vidange au lieu de l’ensemble des entrées. En outre, vu que l’outil est utile de façon générale, le préfixe systemd- lui a été retiré. Les distributions qui veulent maintenir la compatibilité avec l’ancien nom devraient ajouter un lien symbolique de l’ancien nom vers le nouveau.

Pour finir, l’option SplitMode= de journald est maintenant uid par défaut. Cela signifie que les utilisateurs non privilégiés peuvent accéder à leurs propres coredumps avec coredumpctl, sans restrictions.
Et effectivement, j'ai un core-dump pour mon synapse qui vient de crasher malgré mon Storage=none de custom.conf .
À moins que Storage=none ait une fonction moins évidente que je n'aurais pas comprise ?
Edit : pour vérifier, les commandes sont coredumpctl info et coredumpctl -1
Avatar de l’utilisateur
papajoke
Elfe
Messages : 780
Inscription : sam. 30 août 2014, 19:54

Re: [KDE] Extinction du PC longue (résolu)

Message par papajoke »

c'est vrai (oublié/pas utile?) que j'ai aussi un fichier /etc/sysctl.d/50-coredump.conf avec le contenu :

Code : Tout sélectionner

Storage=none
mais surtout avec sysctl, sysctl kernel.core_pattern me retourne :

Code : Tout sélectionner

kernel.core_pattern = |/bin/false
Arch stable - Kde 5 / zsh - btrfs/mbr - Intel Core i3 - 6Go RAM - GeForce 405 video-nouveau
Avatar de l’utilisateur
waitnsea
Maître du Kyudo
Messages : 2114
Inscription : jeu. 15 mars 2012, 05:08

Re: [KDE] Extinction du PC longue (résolu)

Message par waitnsea »

et moi :

Code : Tout sélectionner

kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
Je serais heureux de savoir de quoi il s'agit, papajoke !
Edit ton /etc/sysctl.d/50-coredump.conf semblant plus efficace que mon custom.conf, j'en crée un aussi et j'attends une appli qui crashe...
Edit 2 J'ai rebooté -avec 1'30 d'attente malgré le custom.conf du Wiki, et maintenant, avec ce 50-coredump.conf j'ai la même sortie que toi : kernel.core_pattern = |/bin/false et je reboot sans latence, déjà...
J'aurais mieux fait de lire la totalité du Wiki !
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17285
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [KDE] Extinction du PC longue (résolu)

Message par benjarobin »

Ce qu'a fait papajoke est totalement invalide et n'a pas vraiment de sens...

Pour rappel, pour correctement désactiver les coredump, il existe 2 façons de faire :

Code : Tout sélectionner

ln -s /dev/null /etc/sysctl.d/50-coredump.conf
echo '* hard core 0' >> /etc/security/limits.conf
Je conseil de faire au minimum la première, et personnellement j'ai fait les 2. Si c'est bien fait

Code : Tout sélectionner

cat /proc/sys/kernel/core_pattern
retourne

Code : Tout sélectionner

|/bin/false 
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Répondre