Vous n'êtes pas identifié(e).
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
... à l'arrêt ou redémarrage de la machine, le fichier est fermé brusquement ...
Quelle commande est utilisée pour l'arrêt de cette machine ?
Il doit sûrement être possible de faire en sorte que cette commande (d'arrêt brutal) ne puisse être exécutée que si la présentation a bien été arrêtée et son fichier de présentation correctement fermé.
EDIT:
Après vérification, le signal envoyé à LibreOffice est le signal SIGTERM.
Donc, ce n'est pas la commande qui provoque cet arrêt brutal, mais l'interprétation "personnelle" qu'en fait LibreOffice.
Dernière modification par MicP (15-08-2013 08:35:47)
Dernière modification par Mik (13-08-2013 14:17:45)
Hors ligne
Il doit sûrement être possible de faire en sorte que cette commande (d'arrêt brutal) ne puisse être exécutée que si la présentation a bien été arrêtée et son fichier de présentation correctement fermé.
Oui, c'est ce que je préférerez faire, plutôt que de contourner le problème.
Dernière modification par Mik (13-08-2013 14:19:44)
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
Je suis aussi sur Twitter et nouvellement sur Diaspora*
Mon blog de geekeries : HAL-9000
(J'applique la règle de proximité)
Hors ligne
... qui lance la commande shutdown ...
Alors, reste à savoir de quelle façon la commande "shutdown" est appelée:
Entre la détection par le système de l'appuis sur la touche d'alimentation
et le lancement de la commande "shutdown",
il doit être possible d'intercaler une commande
fermant "proprement" le fichier de présentation,
et n'autorisant le lancement de la commande "shutdown" que si plus aucun processus libre office et fichier associé ne soit ouvert.
La commande "shutdown" (activée par le bouton d'alimentation) est peut-être elle même lancée depuis un script
dans lequel il sera possible de faire ces test de condition d'arrêt du système et de la machine.
Dans un premier temps, il faudrait donc réaliser un script qui fermerait (proprement) Libre Office et sa présentation en cours.
Puis vérifier que la présentation redémarre correctement (sans demande de " Lancer la réparation").
EDIT: Zut! j'avais pas lu:
... J'ai l'impression, après avoir fait quelques rechercher rapides, qu'il n'est pas facile de quitter proprement LibreOffice en passant par une commande… ...
Je vais quand même chercher de mon côté, mais je n'ai jamais créé de fichier de présentation.
Où trouver un exemple de fichier de présentation ? (un lien ou autre)
Mais il y a peut-être mieux:
Si Libre Office demande de Lancer la réparation, c'est qu'il est retourné dans le mode d'édition à la fin de la présentation.
En fait, l'option de commande de démarrage de LibreOffice "-show {filename.odp}" => Starts with the Impress file {filename.odp} and starts the presentation. Enters edit mode after the presentation.
Il faudrait donc trouver un mode de lancement qui ne retourne pas en mode édition pour ne plus avoir de message "Lancer la réparation" au démarrage suivant.
Pourtant, je viens de faire un essai avec un fichier de présentation lancé avec cette commande, et la touche "esc" arrête la présentation et ferme libre office sans passer par le mode d'édition...
Mais un "kill -15" sur le processus de libre office provoque bien ce problème à la réouverture.
Dernière modification par MicP (13-08-2013 19:11:07)
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dernière modification par MicP (13-08-2013 19:40:52)
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
... au final je doute que le résultat soit plus élégant que la solution que j'ai proposée ...
Tout-à fait d'accord avec toi.
Je vais essayer avec un kill -15 après avoir utilisé "-norescue" pour voir.
EDIT:
Zut!
Avec "soffice -show -norescue -view fichier.odp", il démarre pas le diaporama en plein écran. peut-être que mon fichier de test n'est pas bien fait.
Par contre, avec "soffice -show -norescue fichier.odp", là il démarre en diaporama plein écran.
Mais suite à un lancement avec "soffice -show -norescue fichier.odp" puis kill -15 sur le process, il redémarre quand même sur la demande de récupération. mais je suis pas vraiment sûr et certain que son "shutdown" utilise le signal "sigterm"...
... attendre que loffice soit complètement fermé ...
...identifier le bon loffice si plusieurs tournent ...
avec le retour d'un "ps" ou mieux en récupérant l'id du process au moment du lancement.
... les droits sur la fenêtre X de loimpress ...
Du moment ou la commande shutdown peut être lancée, c'est qu'il a les droit "root", et de toutes façons, j'espère qu'il a lui-même lancé cette présentation.
Et puis, je suppose qu'il n'a pas besoin de lancer plusieurs instances de LibreOffice pour une seule présentation de diaporama...
Dernière modification par MicP (13-08-2013 20:39:36)
captnfab a écrit :... attendre que loffice soit complètement fermé ...
...identifier le bon loffice si plusieurs tournent ...
avec le retour d'un "ps" ou mieux en récupérant l'id du process au moment du lancement.
Euh…
Avec le retour d'un "ps", tu ne vas pas savoir quoi faire si loffice est lancé plusieurs fois, en plus, loimpress est un wrapper pour soffice et donc le ps à faire est à grepper sur soffice…
En récupérant le pid, faut faire gaffe… Il y a des soucis de sécurité et de robustesse là-dessous.
Genre, si tu fais le kill en root, le user peut mettre le pid qu'il veut avant et donc forcer root à killer n'importe qui.
Si tu fais le kill en user, dans ce cas le pid peut tjrs être modifié mais sans grave conséquence (juste l'échec du kill)
Bon, tu t'en fiches un peu vu que tu veux redémarrer ta machine dans un cas très particulier, mais bon, c'est sale.
Ensuite, ce pid récupéré, je ne sais pas si c'est celui du script wrapper loimpress ou de soffice…
captnfab a écrit :... les droits sur la fenêtre X de loimpress ...
Du moment ou la commande shutdown peut être lancée, c'est qu'il a les droit "root", et de toutes façons, j'espère qu'il a lui-même lancé cette présentation.
Ça n'est pas le problème.
il ne suffit pas d'être root.
Il faut identifier le « DISPLAY ».
Puis il faut être autorisé par le xhost ou identifier le user et se logguer en tant que le user.
Ça aussi c'est très sale.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dernière modification par MicP (13-08-2013 20:38:27)
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
il ne suffit pas d'être root.
Il faut identifier le « DISPLAY ».
En fait, même pas, il suffit juste d'être l'user qui a créé la fenêtre.
Donc, pas besoin d'avoir un accès avec les privilèges du compte "root" ni par "sudo" pour avoir le droit d'envoyer des touches à SA fenêtre, afin de pouvoir fermer proprement la fenêtre qu'on a créé,
et c'est quand même bien légitime, il me semble.
=============
Alors, pour installer "xdotool" :
=============
Ensuite, pour tester, si la commande de lancement du fichier de diaporama a été:
alors, le script suivant permettra de fermer le diaporama proprement :
Il envoie la touche "-" (moins) à la fenêtre du diaporama en cours d'exécution ce qui va fermer l'application "soffice" qui permet de l'afficher.
Une fois fermé de cette façon, le diaporama redémarrera sans la "demande de récupération".
=================
Mais on peut aussi faire encore plus propre en chaînant les commandes de "xdotool":
Donc, en considérant que le diaporama est en cours d'affichage (=> utilisation de "getactivewindow" ou "getwindowfocus" ),
il suffirait de mettre le bout de code suivant dans le script qui va recevoir l'évènement de la touche M/A,
qui pourra ensuite appeler la commande "shutdown" s'il n'y a plus de process "soffice" actif.
=================
Bien sûr, à chaque fois que LibreOffice va modifier le raccourcis clavier qui permet d'arrêter un diaporama en cours, il faudra adapter le script en conséquence.
Mais bon, je ne pense pas que LibreOffice modifie ça du jour au lendemain.
Maintenant, il y a peut-être solution plus propre, mais je la connais pas, en fait j'apprends tous les jours un petit peu.
Dernière modification par MicP (19-09-2013 23:10:29)
captnfab a écrit :il ne suffit pas d'être root.
Il faut identifier le « DISPLAY ».En fait, même pas, il suffit juste d'être l'user qui a créé la fenêtre.
Non, il faut identifier le DISPLAY
Ton tuto sur xdotool est sympa, je le verrai bien dans le Wiki moi, ça peut être amusant
=============
Alors, pour installer "xdotool" :sudo apt-get update && sudo apt-get install xdotool
=============
Ensuite, pour tester, si la commande de lancement du fichier de diaporama a été:$ soffice -show fichier_diaporama.odp
alors, le script suivant permettra de fermer le diaporama proprement :
Il envoie la touche "-" (moins) à la fenêtre du diaporama en cours d'exécution ce qui va fermer l'application "soffice" qui permet de l'afficher.WID=`xdotool search "SOFFICE" | head -1` # récup de l'ID de la fenêtre X11.
xdotool windowactivate --sync $WID # ça c'est juste pour la remettre au premier plan pour le test.
xdotool key --clearmodifiers "minus" # on lui envoie un evènement clavier correspondant à l'appuis et au relachement de la touche "-" (moins).Une fois fermé de cette façon, le diaporama redémarrera sans la "demande de récupération".
=================
Mais on peut aussi faire encore plus propre en chaînant les commandes de "xdotool":
Donc, en considérant que le diaporama est en cours d'affichage (=> utilisation de "getactivewindow" ou "getwindowfocus" ),
il suffirait de mettre le bout de code suivant dans le script qui va recevoir l'évènement de la touche M/A,
qui pourra ensuite appeler la commande "shutdown" s'il n'y a plus de process "soffice" actif.xdotool getactivewindow key --clearmodifiers "minus"
Supposons que tu aies dans ton serveur X une fenêtre dont le nom soit "Pouet".
Si tu ouvres un terminal dans cette même session X et fais
alors tu vas recevoir le Window ID de la fenêtre.
En revanche, si tu fais cela depuis un tty, ou depuis le script de pré-shutdown lancé par un événement ACPI (après avoir fait un su - tonuser), tu vas recevoir
En effet, avant de pouvoir explorer les ressources X et interagir avec elles, tu as besoin de définir la variable DISPLAY. Et c'est logique, un même utilisateur peut avoir plusieurs serveurs X (éventuellement différents) tournant en même temps.
Par défaut, le DISPLAY utilisé est ":0"
Donc si tu fais
cela devrait fonctionner. Mais cela signifie que tu vas supposer dans ton script que le display utilisé est ":0". Ou alors, tu vas à nouveau demander à ton user de stocker cette valeur dans un fichier pour la récupérer par la suite depuis ton script, ce qui nous ramènes aux problèmes de sécurité vu plus haut.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dernière modification par MicP (14-08-2013 09:22:38)
et pourquoi pas fermer la session utilisateur à tant qu'à faire.
En fait, lors de l'arrêt, le système envoie un SIGTERM à toutes les applications. Celles qui refusent de se fermer reçoivent un SIGKILL et donc, se ferment... Donc, ce mécanisme existe déjà.
Pour le tuto, j'y penserai, mais il me faudra d'abord bien me reposer, apprendre à bien utiliser "xdotool", réviser X11, etc...
Haha, pas besoin d'être au top de partout pour tutoter, sinon personne ne tutoterait.
Mais je ne te presse pas, tu fais ça quand tu veux et surtout si tu veux.
Hop,
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
... En fait, lors de l'arrêt, le système envoie un SIGTERM à toutes les applications. ...
C'est bien là qu'est l'os, rien qu'avec un SIGTERM (le kill -15 que j'avais testé plus haut), c'était la cata au moment de la réouverture de la présentation "soffice",
d'où ma suggestion de détourner l'appel à shutdown en le faisant précéder d'un script.
Mais, il sera peut être plus judicieux d'utiliser le signal de l'ACPI pour ça.
En fait, je n'ai pas assez d'expérience pour savoir laquelle des deux sources il conviendrait d'utiliser : ACPI ou script shutdown.
Réflexion faite, je pense qu'il vaudrait mieux utiliser le déclencheur plutôt que le déclenché, histoire de pas modifier le comportement du déclenché (shutdown).
Reste donc à trouver les méthodes de récupération des événements bouton ACPI, ou trouver le moyen de modifier la fonctionnalité associé à ca bouton. => yfoyaka
Dernière modification par MicP (15-08-2013 05:44:07)
... SIGTERM a plus pour but de demander gentiment de s'arrêter, permettant un nettoyage et la fermeture de fichiers. ...
et c'est bien la fermeture "brutale" des fichiers de LibreOffice par LibreOffice en réponse au signal SIGTERM qui pose problème, le message "Lancer la réparation" à la ré-ouverture du fichier n'en est que la conséquence.
Il faudrait peut-être demander de l'aide à ce sujet dans le forum de Libre Office
===================
Dernière modification par MicP (15-08-2013 09:23:03)