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

Posté par  . Licence CC By‑SA.
Étiquettes :
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  (site web personnel) . É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  . Évalué à 2. Dernière modification le 26 août 2013 à 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  . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.