Forum Linux.debian/ubuntu [ Résolu ] Encore un problème de mise en veille/hibernation suite à mise à jour xubuntu

Posté par . Licence CC by-sa
Tags : aucun
1
9
juin
2014

Bonjour.

Encore un problème récurrent lors de mises à jour Linux (xubuntu), et qui comence à me gaver sérieusement.

Je viens de faire la mise à jour vers la nouvelle XUbuntu LTS. Cependant, comme presqu'à chaque fois, l'hibernation ne fonctionne pas:
* le système ne se met pas en hibernation lorsque je ferme le portable : il se met dans un état de pseudo-veille duquel je ne peux revenir.

  • si je sélectionne l'hibernation en tentant une déconnection :
    • j'ai une fenetre de demande d'authentification (soit disant que d'autres utilisateurs sont connectés, mais ce n'est pas le cas)
    • j'obtiens un message d' "insulte" DBUS Error, et l'hibernation ne se fait pas. Le message :

Échec à la mise en hibernation de la session

GDBus.Error:org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Cependant, si je refais une tentative d'hibernation, cette fois-ci ça fonctionne (long, mais le système se met en hibernation). La fermeture du portable entraine aussi cette hibernation.

Je soupconne donc un problème de droits dans cette saleté de PolicyKit ou un truc du genre. Ce que je souhaiterais, c'est de ne pas avoir à m'authentifier lorsque je demande une mise en hibernation, ce qui règlerait probablement le problème de fermeture du couvercle.

Auriez-vous une idée ?

Merci d'avance.

Cordialement.

  • # Et voilà, ça commence ....

    Posté par . Évalué à 1.

    Cette saleté de systemd n'est pas encore intégrée à Ubuntu qu'elle me pourrit déjà la vie. Je le sentais arriver depuis un moment : j'avis déjà un problème d'hibernation sur la précédente version d'Ubuntu (mais qui ne posait pas problème lorsque je fermais le portable) Le message que j'avais :

    GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

    totof@bipbip:~$ pkaction --action-id org.freedesktop.login1.hibernate
    org.freedesktop.login1.hibernate
    totof@bipbip:~$ pkaction --action-id org.freedesktop.login1.hibernate --verbose
    org.freedesktop.login1.hibernate:
    description: Hibernate the system
    message: Authentication is required for hibernating the system.
    vendor: The systemd Project
    vendor_url: http://www.freedesktop.org/wiki/Software/systemd
    icon:

    implicit any: auth_admin_keep
    implicit inactive: auth_admin_keep
    implicit active: yes

    Mes pires cauchemars se réalisent : tout ce que je préssentais est hélas en train de se produire. Je crois que je vais laisser tomber Linux et faire comme d'autres ont fait avant moi : passer à MacOSX.

    • [^] # Re: Et voilà, ça commence ....

      Posté par (page perso) . Évalué à 5.

      Mes pires cauchemars se réalisent : tout ce que je préssentais est hélas en train de se produire. Je crois que je vais laisser tomber Linux et faire comme d'autres ont fait avant moi : passer à MacOSX.

      C'est bien, ça nous ferra des vacances.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Et voilà, ça commence ....

        Posté par . Évalué à 3.

        Ne rêve pas: je continuerai à sévir ici. Sinon, pour en revenir au sujet, essaie de défendre sustemd et la bande à Pottering sur ce coup.

        • [^] # Re: Et voilà, ça commence ....

          Posté par . Évalué à 1.

          Je ne sais pas si c'est un point faible de Linux ou des distribution Debian et dérivée mais j'ai toujours eu du mal avec la mise en veille sur ma tour. Soit ça ne fonctionnait pas, soit ça fonctionnait mal.
          J'aurais, sans doute, pu trouver un contournement si j'avais eu une vrai raison d'utiliser la veille.
          Juste pour dire que la veille c'est un vrai problème sur Linux et je penses que systemd ou autre, lorsqu'on aura des pilotes fabricants corrects et intégrés comme il faut, j'ai l'impression que les problèmes de mise en veille seront moins fréquent.

          Julien_c'est_bien (y'a pas que Seb)

        • [^] # Re: Et voilà, ça commence ....

          Posté par (page perso) . Évalué à 2. Dernière modification le 10/06/14 à 14:45.

          C'est vrai, j'aimerai connaître le rapport entre une mise à jour qui a foiré et systemd…

          Ici, que ce soit Ubuntu ou Kubuntu, l'hibernation fonctionne très bien… Et ça marche aussi avec des OS 100% systemd comme arch.

        • [^] # Re: Et voilà, ça commence ....

          Posté par . Évalué à 4.

          Je ne sais pas si c'est spécifiquement lié à systemd, mais je vois qu'on n'est pas si isolé que ça :
          https://fr.wikipedia.org/wiki/PolicyKit#Pol.C3.A9mique

          Tous ces trucs dont on ne comprend rien (en tant que simple utilisateur), avec une syntaxe affreuse (yabon l'édition des fichiers xml), et dans des chemins faciles à retrouver et à écrire, du genre /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla … c'est pas la joie…

          • [^] # Re: Et voilà, ça commence ....

            Posté par . Évalué à 3.

            Alors entre :
            - un bout de config XML
            - un bout de config déclaratif de style


            [machintruc]
            xyz=toto.titi.tata
            abc=yes

            - l'arrivée de Javascript pour déclarer les règles
            - les fichiers répartis entre /etc/polkit-1, /var/polkit1 + les sous-arborescences de ces rep
            - les interactions avec dbus (qui ne sont pas simples non plus),

            ça devient compliqué de s'y retrouver. C'est cette horreur qu'il aurait fallu reprendre avant de s'interesser au système de démarrage de Linux : là le système se base sur un truc pourri d'avance, et ça n'aide pas.

    • [^] # Re: Et voilà, ça commence ....

      Posté par . Évalué à 2.

      J'ai systemd sur Archlnux, sur un ASUS N56VV (UEFI), et la mise en veille/hibernation/arrêt/redémarrage/verrouillage sont OK.

      Quant ça ne fonctionnait pas, c'était à cause du BIOS sur mon ancienne machine (ASUS x71SL).

      Haters gonna hate…

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Test

    Posté par (page perso) . Évalué à 5.

    Tu pourrais commencer par vérifier que les mécanismes bas-niveaux d'hibernation fonctionnent.

    Pour cela, lance un terminal, log-toi en root (sudo bash), et lance un :

    /usr/sbin/pm-suspend pour mettre en veille
    ou
    /usr/sbin/pm-hibernate pour hiberner

    Il y a des fichiers de logs dans /var/log/pm-*

    Une fois cette partie-là validée, tu pourras regarder du coté de policikit.

    Mais je suspecte que le problème vienne de XFCE : En effet, sur quelques machines que j'ai (Debian Testing) les upgrades de XFCE changent parfois les droits de l'utilisateur pour le shutdown/reboot/etc…

    A noter que cela peut aussi venir du gestionnaire de session : gdm/gdm3/lightdm/slim, etc…

    • [^] # Re: Test

      Posté par . Évalué à 2.

      Bonjour.

      Tu pourrais commencer par vérifier que les mécanismes bas-niveaux d'hibernation fonctionnent.

      Déjà fait, et àa fonctionne. D'ailleurs, tu remarqueras que lorsque je tente une fois la mise en hibernation via la déconnection, j'ai une demande d'authentification (parce que soit-disant il y a quelqu'un d'autre de connecté alors que ce n'est pas le cas), un message d'erreur dbus, et ensuite, comme par magie, ça fonctionne …. C'est pour ça que je soupçonnais un problème de droits via policykit, et en y réfléchissant, je suppute un problème de communication via dbus.

      Merci cependant pour cette suggestion.

      Mais je suspecte que le problème vienne de XFCE : En effet, sur quelques machines que j'ai (Debian Testing) les upgrades de XFCE changent parfois les droits de l'utilisateur pour le shutdown/reboot/etc…

      Ca c'est possible, cependant normalement les droits sont OK. Ce que je trouve étrange, c'est cette demande de mot de passe lorsque je mets en veille via la GUI. Il est fort probable que lorsque je ferme le portable, la machine considère que tant que je ne suis pas authentifié, je n'ai pas le droit de mettre la machine en hibernation …

  • # Aléatoire

    Posté par (page perso) . Évalué à 2.

    Pour ma part :

    • 1 machine (4-5 ans) sous (Gnome)buntu 14.04, cpu et gfx AMD (pilotes libres) : fonctionne au poil
    • 1 machine (1 an) Debian Wheezy, 100% intel (cpu et gpu intégré, pilotes libres) : idem
    • 1 machine (Zotac Nano AD10), Xubuntu 12.04 la veille n'était pas fiable. Upgradée vers la 14.04, toujours pas 100% fiable. Pilotes ati libres.

    3 configs totalement différentes.

    Pour résoudre ton souci, il faudrait au moins ré-essayer avec un OS fraîchement réinstallé.

    • [^] # Re: Aléatoire

      Posté par . Évalué à 2.

      Je ne pense pas que ce soit utile, et surtout je n'ai pas de disque dispo pour une réinstallation complète.

      Sinon, après quelques recherche, je constate qu'il s'agit bien d'un problèùme de règle policykit.

      Sinon, j'ai fait une petite modif dans la configuration xfce4 : l'insulte dbus a disparue. Cependant, j'ai toujours une demande d'authentification lors de l'hibernation via la fenêtre de déconnection. La ou c'est intéressant, c'est que la fenêtre de demande de mot de passe me donne l'identifiant de l'action qui nécessite l'authentification : je devrais pouvoir m'en sortir avec ça.

      Sinon, y a-t-il un moyen de lancer le daemon polkit en debug pour pouvoir tracer les actions autorisées ou refusées par polkit ?

      • [^] # Re: Aléatoire

        Posté par . Évalué à 3.

        Problèmes résolus : je détaillerai un peu plus tard (je n'ai pas le portable à portée de main pour le moment), mais il y avait deux causes :
        - une liée à polkit, qui est une horreur à gérer (il y a des fichiers de conf un peu partout, et si on ne met pas les directives dans le bon fichier ça ne marche pas)
        - une liée à logind qui semble vouloir s'occuper de la gestion d'énergie (ce n'est pas son rôle à priori), et qui se moque totalement des directives que j'ai configurées via l'IHM.

        • [^] # Re: Aléatoire

          Posté par (page perso) . Évalué à 1. Dernière modification le 12/06/14 à 19:11.

          Un truc à savoir :

          l'hibernation n'est plus automatiquement activée depuis ubuntu 14.04, selon les machines.
          (Voire même désactivée par défaut)

          Du coup c'est peut-être pour ça que depuis ton upgrade ça ne fonctionnait plus.

          https://help.ubuntu.com/community/PowerManagement/Hibernate#Hibernate_Disabled_by_Default

          https://help.ubuntu.com/14.04/ubuntu-help/power-hibernate.html

          • [^] # Re: Aléatoire : La solution

            Posté par . Évalué à 3.

            Ce n'est pas suffisant : j'avais fait cette manip, et ça ne fonctionnait toujours pas : voir plus bas mon explication.

            Voici un extrait de la manpage de logind pour les explications :

            http://manpages.ubuntu.com/manpages/trusty/man5/logind.conf.5.html

            
                 IdleAction=
                           Configures the action to take when the system is idle. Takes one of
                           ignore, poweroff, reboot, halt, kexec, suspend, hibernate,
                           hybrid-sleep, lock. Defaults to ignore.
            
                           Note that this requires that user sessions correctly report the
                           idle status to the system. The system will execute the action after
                           all sessions reported that they are idle, and no idle inhibitor
                           lock is active, and subsequently the time configured with
                           IdleActionSec= (see below) has passed.
            
                [ ... ]
            
                HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=,
                       HandleLidSwitch=
                           Controls whether logind shall handle the system power and sleep
                           keys and the lid switch to trigger actions such as system power-off
                           or suspend. Can be one of ignore, poweroff, reboot, halt, kexec,
                           suspend, hibernate, hybrid-sleep and lock. If ignore logind will
                           never handle these keys. If lock all running sessions will be
                           screen locked. Otherwise the specified action will be taken in the
                           respective event. Only input devices with the power-switch udev tag
                           will be watched for key/lid switch events.  HandlePowerKey=
                           defaults to poweroff.  HandleSuspendKey= and HandleLidSwitch=
                           default to suspend.  HandleHibernateKey= defaults to hibernate.
            

            Il faut donc éditer dans /etc (ou le sous répertoire logind de /etc, je ne me rappelle plus) le fichier logind.conf, décommenter la ligne HandleLidSwitch=suspend (me semble-t-il, ou autre chose …) et remplacer suspend(ou autre chose) par hibernate pour obtenir :

            HandleLidSwitch=hibernate
            

            Pour polkit et l'hibernation depuis le menu de déconnection : il y a eu modification de comportement depuis la mise à jour : autrefois, le mot de passe n'était demandé uniquement lorsque d'autres utilisateurs étaient connectés. Maintenant, le mot de passe est demandé même s'il n'y a pas d'autres utilisateurs connectés.

            Deux possibilités :
            - soit une nouvelle règle polkit a été ajoutée
            - soit un bug : le système croit qu'il y a d'autres utilisateurs de connectés alors que ce n'est pas le cas ( personnellement, j'ai de gros soupçons envers logind ). J'ai du modifier la conf de polkit pour que le mot de passe ne soit pas demandé. Par contre dans un premier temps je n'avais pas placé mon fichier au bon endroit donc ma modif n'était pas pris en compte.

            Ce changement de comportement m'a quelque peu induit en erreur sur la cause initiale du problème. Je n'ai pas essayé de supprimer la règle polkit que j'ai modifiée suite à cette modification de comportement. Il est possible, voire fort probable que la mise en hibernation se fasse en fermant le portable sans cette règle. Je testerai ce week-end (là pour le moment, ça fonctionne, et je n'ai pas envie de passer des heures à tout reconfigurer).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.