Forum général.général [Résolu (salement)]fermer xmonad proprement

Posté par . Licence CC by-sa
Tags :
2
25
août
2013

Bonjour à tous,
J'ai un problème avec xmonad, présentement, la clé qui permet de le quitter (celle proposer dans le fichier de conf donné en exemple sur le site officiel) est plutôt brutale : ((modm .|. shiftMask, xK_q ), io (exitWith ExitSuccess)), exitWith se comportant basiquement comme le exit de C.

Les processus fils d'xmonad sont ensuite massacrés je ne sais comment, ce qui me pose problème c'est surtout firefox qui redémarre ensuite comme s'il avait été tué à coup de SIGKILL, et le fait que les processus emacsclient étant tué n'importe comment, j'ai le démon emacs qui se met à boucler et prendre tout les CPU jusqu’à ce qu'il soit tué à son tours (par moi) (et il n'accepte plus de connexion).

J'aurais trois question: si le processus xmonad quitte, il laisse tout ses processus fils orphelins, et je ne sais pas du tout ce qu'il leur arrive comme X quitte lui aussi. Qu'est-ce qu'il leur arrive à ses processus ?

D'autre part je me demande quelle est la manière propre de fermer un gestionnaire de fenêtre avec des processus dedans.

Et enfin, comment est-ce que je peux faire pour récupérer des informations utiles pour faire un rapport de bug correct pour emacs, j'ai essayé de tuer emacsclient avec plusieurs signaux, mais aucun ne provoque la boucle dans le serveur, ça a vraiment l'air spécial la manière dont il est tué par le système.

J'utilise Arch avec les paquets à jour, emacs 24.3.1, xmonad 0.11 (celui des dépots arch), firefox 23.0.1, et xorg 1.14.2. Voilà, je ne sais pas trop quoi faire…

Merci beaucoup :)

  • # Emacs

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

    Je n'utilise pas Xmonad, alors je ne pourrais pas te répondre là-dessus.

    Par contre, pour emacs, tuer emacsclient ne tue pas le serveur lancé avec emacs --daemon, puisque se sont deux processus indépendants.
    Si tu veux tuer le serveur en quittant emacsclient, il te faut lancer la commande suivante : M-x kill-emacs.

    Enfin, pour ce qui est de remonter un bogue, il y a déjà toutes les informations dans emacs : M-x info-emacs-bug.

    • [^] # Re: Emacs

      Posté par . Évalué à 3.

      Vi, je voulais pas tuer mon démon mais le problème c'est qu'en fermant xmonad et X avec un client connecté, le démon plantait, et il n'était plus possible de s'y connecter, j'étais alors obligé de le tué à coup de kill -9.

      Donc voilà :) je vais essayer de reproduire le bug avec un joli script, sans xmonad.

      Please do not feed the trolls

  • # killWindow?

    Posté par (page perso) . Évalué à 2. Dernière modification le 26/08/13 à 10:16.

    Une idée mais j'ai pas essayé : utiliser withWindowSet de Xmonad.Core puis allWindows de Xmonad.Stack pour récupérer la liste des fenêtres et les tuer à coup de killWindow de Xmonad.Opérations (la même fonction utilisée pour alt+shift+c, donc normalment firefox devrait bien se fermer).

    Sinon j'ai remarqué avec pstree que firefox n'est pas un fils de xmonad ni de X.

    • [^] # Re: killWindow?

      Posté par . Évalué à 2.

      Une idée mais j'ai pas essayé : utiliser withWindowSet de Xmonad.Core puis allWindows de Xmonad.Stack pour récupérer la liste des fenêtres et les tuer à coup de killWindow de Xmonad.Opérations (la même fonction utilisée pour alt+shift+c, donc normalment firefox devrait bien se fermer).

      Très bonne idée :) Ça marche (modulo l'asynchronicité de la chose), j'ai cependant du temporisé la chose pour que ça marche vraiment)

            ((modm .|. shiftMask, xK_q     ),  do withWindowSet $ mapM_ killWindow . W.allWindows
                                                  io $ threadDelay (5 * 10^5)
                                                  io $ exitWith ExitSuccess)

      Du coup, c'est super crade… Mais je vois pas trop comment faire autrement…

      Sinon j'ai remarqué avec pstree que firefox n'est pas un fils de xmonad ni de X.

      Oui, chez moi aussi, j'ai trouvé pourquoi (dans mon cas) je lance tout les processus soit avec le script d'init d'xmonad (en faisant un exec ces processus deviennent les fils d'xmonad) soit avec dmenu_run, et ce petit salaud lance le processus, et meurs… D'où le fait qu'ils se retrouvent rattaché à l'init.

      dmenu_run :

      #!/bin/sh
      cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
      if [ -d "$cachedir" ]; then
          cache=$cachedir/dmenu_run
      else
          cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
      fi
      (
          IFS=:
          if stest -dqr -n "$cache" $PATH; then
              stest -flx $PATH | sort -u | tee "$cache" | dmenu "$@"
          else
              dmenu "$@" < "$cache"
          fi
      ) | ${SHELL:-"/bin/sh"} &

      L'avantage de ce script c'est qu'on peut entrer des commandes shell, l’inconvénient c'est qu'il perd les processus…

      Bref ! Cette solution moche me satisfais, je peux attendre une demie seconde que ça se ferme :) Même si j'espère que firefox ne mettra jamais plus longtemps pour se fermer, je sais qu'il est long parfois

      Please do not feed the trolls

      • [^] # Re: killWindow?

        Posté par . Évalué à 2.

        J'ai adapté mon dmenu_run pour (moins) paumer de processus et économiser un peu de mémoire (l'autre script lance tout dans un nouveau shell du coup…)

        #!/bin/sh
        cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
        if [ -d "$cachedir" ]; then
            cache=$cachedir/dmenu_run
        else
            cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
        fi
        IFS=:
        if stest -dqr -n "$cache" $PATH; then
            exec $(stest -flx $PATH | sort -u | tee "$cache" | dmenu "$@")
        else
            exec $(dmenu "$@" < "$cache")
        fi

        Please do not feed the trolls

      • [^] # Re: killWindow?

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

        Ça marche (modulo l'asynchronicité de la chose)

        C'est vrai, j'avais pas pensé à ça :)

        Ben je vais peut-être mettre la même chose, ça m'a l'air bien! Après je continuerai probablement à tout fermer avant de sortir d'X tellement c'est devenu un réflexe.

        Et pas mal l'idée pour dmenu!

        Même si j'espère que firefox ne mettra jamais plus longtemps pour se fermer, je sais qu'il est long parfois

        Bah, on n'en est pas à quelques secondes près non plus, ça me rappelle un sondage sur le temps que mettait l'ordi pour s'arrêter ;)

Suivre le flux des commentaires

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