# Problème aléatoire sur la veille

**URL:** <https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893>\
**Category:** Support Debian\
**Tags:** veille\
**Created:** [Septembre 14, 2026, 5:28 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893 "2026-09-14T05:28:49Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![Thierz](https://www.debian-fr.org/user_avatar/www.debian-fr.org/thierz/32/15124_2.png) [@Thierz](https://www.debian-fr.org/u/Thierz)\
**Post date:** [Octobre 4, 2026, 12:16 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/21 "2026-10-04T12:16:36Z")

</div>

> [@Zargos](#):
>
> Tu peux utiliser journalctl -b 1 ou -b 2 pour remonter au boot précédent ou à celui avant encore.

Pour info à ceux que ça intéresse, la syntaxe correcte est avec un «&nbsp;-&nbsp;» devant le numéro de boot précédent recherché, pour le boot précédent faire :

```
journalctl -b -1

```

Et pour celui d’encore avant :

```
journalctl -b -2

```

---

<div class="post-metadata">

**Author:** ![Thierz](https://www.debian-fr.org/user_avatar/www.debian-fr.org/thierz/32/15124_2.png) [@Thierz](https://www.debian-fr.org/u/Thierz)\
**Post date:** [Octobre 4, 2026, 12:22 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/22 "2026-10-04T12:22:24Z")

</div>

Voici les dernières lignes de `journalctl` précédant le passage en veille. Les lignes précédentes sont éloignées de 30 secondes donc pour l’instant je ne les lie pas au problème…

```
oct. 03 19:15:19 desktop-t kernel: [UFW BLOCK] IN=enp8s0 OUT= MAC=01:00:5e:00:00:01:90:9a:4a:37:b6:3c:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2  
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:52 desktop-t systemd-logind[899]: The system will suspend now!
oct. 03 19:15:52 desktop-t ModemManager[1015]: <msg> [sleep-monitor-systemd] system is about to suspend
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.6319] manager: sleep: sleep requested (sleeping: no enabled: yes)
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.6321] manager: NetworkManager state is now ASLEEP
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.6324] device (enp8s0): state change: activated -> deactivating (reason 'sleeping', managed-type: 'full')
oct. 03 19:15:52 desktop-t dbus-daemon[889]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.13' (uid=0 pid=1103 comm="/usr/sbin/Netwo>
oct. 03 19:15:52 desktop-t systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
oct. 03 19:15:52 desktop-t dbus-daemon[889]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
oct. 03 19:15:52 desktop-t systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.7598] device (enp8s0): state change: deactivating -> disconnected (reason 'sleeping', managed-type: 'full')
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Withdrawing address record for 2a01:e0a:d6d:ab40:5cc9:718d:5db6:6c96 on enp8s0.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Withdrawing address record for 2a01:e0a:d6d:ab40:3e7c:3fff:fe22:f0a4 on enp8s0.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Leaving mDNS multicast group on interface enp8s0.IPv6 with address 2a01:e0a:d6d:ab40:3e7c:3fff:fe22:f0a4.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Joining mDNS multicast group on interface enp8s0.IPv6 with address fe80::3e7c:3fff:fe22:f0a4.
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.7603] dhcp4 (enp8s0): canceled DHCP transaction
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Registering new address record for fe80::3e7c:3fff:fe22:f0a4 on enp8s0.*.
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.7603] dhcp4 (enp8s0): activation: beginning transaction (timeout in 45 seconds)
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Withdrawing address record for fe80::3e7c:3fff:fe22:f0a4 on enp8s0.
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.7603] dhcp4 (enp8s0): state changed no lease
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Leaving mDNS multicast group on interface enp8s0.IPv6 with address fe80::3e7c:3fff:fe22:f0a4.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Interface enp8s0.IPv6 no longer relevant for mDNS.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Withdrawing address record for 192.168.1.249 on enp8s0.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Leaving mDNS multicast group on interface enp8s0.IPv4 with address 192.168.1.249.
oct. 03 19:15:52 desktop-t avahi-daemon[887]: Interface enp8s0.IPv4 no longer relevant for mDNS.
oct. 03 19:15:52 desktop-t kscreenlocker_greet[56175]: PAM unable to dlopen(pam_sss.so): /usr/lib/security/pam_sss.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce nom
oct. 03 19:15:52 desktop-t kscreenlocker_greet[56175]: PAM adding faulty module: pam_sss.so
oct. 03 19:15:52 desktop-t NetworkManager[1103]: <info> [1791047752.8879] device (enp8s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping', managed-type: 'full')
oct. 03 19:15:52 desktop-t kernel: r8169 0000:08:00.0 enp8s0: Link is Down
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:52 desktop-t kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
oct. 03 19:15:53 desktop-t systemd[1]: Reached target sleep.target - Sleep.
oct. 03 19:15:53 desktop-t systemd[1]: Starting systemd-suspend.service - System Suspend...
oct. 03 19:15:53 desktop-t systemd[1]: user@1000.service: Unit now frozen-by-parent.
oct. 03 19:15:53 desktop-t systemd[1]: session-4.scope: Unit now frozen-by-parent.
oct. 03 19:15:53 desktop-t systemd[1]: user-1000.slice: Unit now frozen-by-parent.
oct. 03 19:15:53 desktop-t systemd[1]: user.slice: Unit now frozen.
oct. 03 19:15:53 desktop-t systemd-sleep[56195]: Successfully froze unit 'user.slice'.
oct. 03 19:15:53 desktop-t systemd-sleep[56195]: Performing sleep operation 'suspend'...

```

Ensuite plus rien. Vers 19:40 j’ai tenté une sortie de veille qui a planté, et qui n’a vraisemblablement rien mis dans le journal… Les deux seules lignes en erreur du paquet sont les suivantes, mais elles sont également présentes lors d’une sortie de veille réussie, donc je ne les pointe pas du doigt :

```
PAM unable to dlopen(pam_sss.so): /usr/lib/security/pam_sss.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce nom
PAM adding faulty module: pam_sss.so
```

---

<div class="post-metadata">

**Author:** ![Thierz](https://www.debian-fr.org/user_avatar/www.debian-fr.org/thierz/32/15124_2.png) [@Thierz](https://www.debian-fr.org/u/Thierz)\
**Post date:** [Octobre 4, 2026, 12:28 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/23 "2026-10-04T12:28:09Z")

</div>

Lors d’un passage en veille qui se réveille, les lignes de journal avant l’hibernation sont :

```
sept. 22 08:28:41 desktop-t systemd[1]: Reached target sleep.target - Sleep.
sept. 22 08:28:41 desktop-t systemd[1]: Starting systemd-suspend.service - System Suspend...
sept. 22 08:28:41 desktop-t systemd[1]: user@1000.service: Unit now frozen-by-parent.
sept. 22 08:28:41 desktop-t systemd[1]: session-3.scope: Unit now frozen-by-parent.
sept. 22 08:28:41 desktop-t systemd[1]: user-1000.slice: Unit now frozen-by-parent.
sept. 22 08:28:41 desktop-t systemd[1]: user.slice: Unit now frozen.
sept. 22 08:28:41 desktop-t systemd-sleep[11649]: Successfully froze unit 'user.slice'.
sept. 22 08:28:41 desktop-t systemd-sleep[11649]: Performing sleep operation 'suspend'...
sept. 22 08:28:41 desktop-t kernel: PM: suspend entry (deep)
sept. 22 08:28:41 desktop-t kernel: Filesystems sync: 0.008 seconds

```

Il se trouve que ces deux lignes sont absentes lorsque la mise en veille plante :

```
sept. 22 08:28:41 desktop-t kernel: PM: suspend entry (deep)
sept. 22 08:28:41 desktop-t kernel: Filesystems sync: 0.008 seconds
```

---

<div class="post-metadata">

**Author:** ![damale88](https://www.debian-fr.org/user_avatar/www.debian-fr.org/damale88/32/15523_2.png) [@damale88](https://www.debian-fr.org/u/damale88)\
**Post date:** [Octobre 8, 2026, 6:13 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/24 "2026-10-08T18:13:56Z")

</div>

La solution que j’ai proposé ne semble pas fonctionner. Dernièrement, mon ordinateur a gelé lors de la mise en veille

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Octobre 8, 2026, 6:31 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/25 "2026-10-08T18:31:30Z")

</div>

> [@Thierz](#):
>
> `user.slice: Unit now frozen.`

Ce message signifie que systemd a mis la session utilisateur sous « gel (freeze) » pendant la suspension, donc les processus sont interrompus pour laisser le travail en veille. Si cela provoque des blocages ou des échecs, une solution de contournement courante consiste à désactiver le comportement de Freeze en définissant:  
`SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false`  
pour `systemd-suspend.service`.

---

<div class="post-metadata">

**Author:** ![Thierz](https://www.debian-fr.org/user_avatar/www.debian-fr.org/thierz/32/15124_2.png) [@Thierz](https://www.debian-fr.org/u/Thierz)\
**Post date:** [Octobre 8, 2026, 7:03 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/26 "2026-10-08T19:03:08Z")

</div>

J’observe un point que je n’avais pas mentionné… Quand la veille plante, NUM LOCK reste allumé. Quand la veille se passe bien, NUM LOCK s’éteint… Du coup, désormais je peux prédire avant de rallumer le PC s’il va sortir de veille ou pas.

> [@Zargos](#):
>
> `SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false`  
> pour `systemd-suspend.service`

Ça se configure dans quel fichier STP ?

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Octobre 8, 2026, 7:12 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/27 "2026-10-08T19:12:57Z")

</div>

```auto
$ cat /usr/lib/systemd/system/systemd-suspend.service.d/nvidia-suspend-nofreeze.conf
# Systemd does not interact well with Xorg during system suspend when a kernel
# driver requests a VT switch because systemd freezes all userspace processes,
# including Xorg, before triggering kernel suspend. This deadlocks with the Xorg
# server, which can't respond to the request to switch VTs because it was frozen
# by systemd.
#
# For now, disable freeze on suspend.
[Service]
Environment = SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false

```

Modifié via: # systemctl edit systemd-suspend.service

Il se trouve que c’est nécessaire avec NVIDIA apparemment.

---

<div class="post-metadata">

**Author:** ![damale88](https://www.debian-fr.org/user_avatar/www.debian-fr.org/damale88/32/15523_2.png) [@damale88](https://www.debian-fr.org/u/damale88)\
**Post date:** [Octobre 21, 2026, 7:19 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/28 "2026-10-21T19:19:35Z")

</div>

J’ai beaucoup de problème concernant la mise en veille. Une des caractéristiques que j’avais remarqué, c’est que le blocage se produisait surtout quand la mise en veille durait un certains temps

Je comprends Thierz que tu veux une veux comprendre. Mais dans mon cas, je préfère ce bug résolu, que de le comprendre. Tant mieux si je comprends, mais je ne comprends pas tout ce qui se passe dans ma machine, et pourtant j’accepte de l’utiliser. Que ce soit moi qui règle le problème sans comprendre ou un autre, le plus important c’est de trouver une solution, car je trouve innaceptable de fermer abruptement mon ordinateur.

Je comprends quand même ton désir de comprendre. Je comprend que c’est la gestion de la mémoire et j’ai lu que par défaut, les dossiers où sont stockés ces informations, sont souvent petits. Ça viendrait jouer là-dedans

Dans mon cas, j’ai décommenté cette ligne (en enlevant le dièse #)  
options nvidia-current NVreg\_PreserveVideoMemoryAllocations=1  
et j’ai rajouté :  
NVreg\_TemporaryFilePath=/var/tmp

dans le fichier /etc/modprobe.d/nvidia-options.conf

À l’instant, je viens de sortir d’une veille prolongé et je n’ai pas eu d’écran noir qui gèle.

si tu veux des explications, j’ai trouvé la solution ici :  
[https://bbs.archlinux.org/viewtopic.php?id=300008](https://bbs.archlinux.org/viewtopic.php?id=300008)

dans la documentation officielle de NVIDIA, comme le dit Nobert, ils en parlent : [Chapter&nbsp;21.&nbsp;Configuring Power Management Support](https://download.nvidia.com/XFree86/Linux-x86_64/595.84/README/powermanagement.html)

> **[595 release feedback & discussion](https://forums.developer.nvidia.com/t/595-release-feedback-discussion/362561)**
>
> Added support for the VK\_EXT\_descriptor\_heap extension. Fixed a bug that caused GPU hangs and Xid errors in Black Myth: Wukong. Added support for DRI3 version 1.2. Added support for the VK\_EXT\_present\_timing extension. Fixed hang when NVIDIA Smooth...

si je vois que l’écran reste noir, je reviendrai le dire, mais dans le moment, c’est prometteur de mon côté

---

<div class="post-metadata">

**Author:** ![damale88](https://www.debian-fr.org/user_avatar/www.debian-fr.org/damale88/32/15523_2.png) [@damale88](https://www.debian-fr.org/u/damale88)\
**Post date:** [Octobre 21, 2026, 9:35 UTC](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893/29 "2026-10-21T21:35:16Z")

</div>

Fausse alerte, il y a encore eu un gèle d’écran noir

[Page précédente](https://www.debian-fr.org/t/probleme-aleatoire-sur-la-veille/92893.md?page=1)