Déconnexion automatique lors de la reprise de la suspension sur Xubuntu 18.04
Lorsque mon ordinateur portable Xubuntu 18.04 cesse de suspendre, systemd-logind se déconnecte automatiquement de la session en cours si l'ordinateur portable est resté suspendu pendant plus de deux heures. Si l'intervalle entre suspendre et reprendre est court, il ne se déconnectera pas. Je n'ai toujours pas découvert combien de temps cet intervalle doit durer pour provoquer la déconnexion.
J'ai activé le débogage sur le systemd-logind.service, créant le fichier / etc/systemd/system/systemd-logind.service.d/10-debug.conf:
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
ce qui oblige systemd-logind à consigner tous les messages D-Bus qu’il gère, mais n’a pu détecter quoi que ce soit qui aurait pu causer la déconnexion.
J'ai scanné tous les messages du journal systemd (journalctl) avant que systemd-logind ne commence à tuer la session en cours, j'ai enquêté sur tout ce qui semblait suspect mais ne trouvait rien qui puisse influencer une déconnexion automatique. Voici certains des messages qui m'ont semblé suspects (ils ne sont pas séquentiels, mais tirés d'occasions différentes):
upowerd[1600]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0
polkitd(authority=local)[840]: Unregistered Authentication Agent for unix-session:c2 (system bus name :1.46, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
wpa_supplicant[811]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface dbus_property=Stations getter failed
wpa_supplicant[811]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (none) none
at-spi-bus-launcher[7031]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
at-spi-bus-launcher[7031]: after 30333 requests (30333 known processed) with 0 events remaining.
systemd-logind[779]: Inhibitor xfce4-power-manager (xfce4-power-manager handles these events) pid=8611 uid=1000 mode=block stopped
systemd-logind[779]: Electing new display for user paulo
systemd-logind[779]: Ignoring session c8
la configuration de logind n'a rien qui pourrait causer ceci:
paulo:~$ loginctl show-session
EnableWallMessages=no
NAutoVTs=6
KillUserProcesses=no
RebootToFirmwareSetup=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key
DelayInhibited=sleep
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore
HoldoffTimeoutUSec=30s
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
Docked=no
RemoveIPC=yes
RuntimeDirectorySize=615313408
InhibitorsMax=8192
NCurrentInhibitors=5
SessionsMax=8192
NCurrentSessions=1
UserTasksMax=10813
Je ne trouve rien qui puisse causer une déconnexion automatique après un intervalle de temps. Je suis vraiment perplexe.
Pour un crash X intermittent avec SIGBUS le 18.04, veuillez vérifier cette réponse:
Erreur Ubuntu 18.04 au réveil du sommeil: erreur de lecture sur le périphérique d'échange
Quand je pense avoir résolu le problème, il mord à nouveau : . Le problème lui-même est bel et bien causé par le crash du serveur Xorg avec SIGBUS, mais la cause première du crash n'est pas le mauvais comportement du lanceur spi-bus-lanceur. N'effectuez pas la boucle en répétant ces requêtes, la --- (procédure précédente est toujours valide, bien que ce ne soit pas une solution de contournement du crash de Xorg.
J'ai découvert que Xorg utilisait le pilote du noyau i915 :
paulo:~$ Sudo lshw -C video
*-display
description: VGA compatible controller
product: 2nd Generation Core Processor Family Integrated Graphics Controller
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 09
width: 64 bits
clock: 33MHz
capabilities: msi pm vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0
resources: irq:36 memory:f6800000-f6bfffff memory:e0000000-efffffff ioport:f000(size=64) memory:c0000-dffff
J'ai donc essayé une autre solution de contournement, pour forcer Xorg à utiliser xserver-xorg-video-intel avec la méthode d'accélération uxa , qui est plus stable que la valeur par défaut sna .
- Créer un répertoire /etc/X11/xorg.conf.d . Nous pouvons placer des extraits xorg.conf dans ce répertoire et le serveur Xorg les récupère à son démarrage.
- Créer un fichier /etc/X11/xorg.conf.d/10-intel.conf , en ordonnant à Xorg d’utiliser son Pilote vidéo Intel avec méthode d’accélération uxa .
Voici /etc/X11/xorg.conf.d/10-intel.conf :
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "uxa"
EndSection
J'utilise cette solution de contournement depuis une semaine et le serveur Xorg n'est pas tombé en panne. J'ai donc l'impression qu'il s'agit de la solution définitive alors que Xorg n'est pas corrigé.
J'ai ouvert un rapport de bogue contre Xorg, qui semble apparemment affecter davantage d'utilisateurs, car il a été signalé comme un doublon de n autre bogue , que je n'ai pas détecté. au début puisque son titre mentionne un autre type de crash.
J'ai confirmé que ce problème est dû au crash du serveur Xorg avec SIGBUS. Le serveur Xorg se bloque et systemd-logind crée une nouvelle session de connexion.
Le serveur Xorg se bloque à cause d'un nombre excessif de requêtes de at-spi-bus-launcher . Juste avant chaque crash, des messages tels que ceux-ci étaient enregistrés dans le journal de systemd:
at-spi-bus-launcher[31720]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
at-spi-bus-launcher[31720]: after 8065 requests (8065 known processed) with 0 events remaining.
Il semble être un problème documenté, que Xorg se bloque lorsqu'il reçoit un nombre excessif de demandes sans intervalle.
Pour contourner ce bogue, 2 étapes sont nécessaires:
- Désinstallez le paquet
at-spi2-core - Ajoutez
export NO_AT_BRIDGE=1à . Profile , afin que les applications GTK ne se plaignent pas de l'absence du bus d'accessibilité
Xorg ne s'est plus jamais écrasé après cette solution de contournement et, par conséquent, il n'y avait plus de déconnexion automatique après la reprise de la suspension.
J'ai déposé un rapport de bogue contre at-spi sur Gnome BugZilla.