Forum Linux.redhat Nautilus: perte connection SFTP après wakeup from sleep

Posté par  .
Étiquettes :
0
2
mai
2011

Bonjour à tous,

Sous Fedora 14, j'ai souvent de multiples fenêtres/onglets Gedit et Nautilus ouverts sur un serveur distant. J'utilise le protocole SFTP de Nautilus.

Lorsque je fais un suspend to RAM, puis un wake-up le lendemain matin, les fenêtres/onglets Nautilus se ferment, alors que les fenêtres/onglets Gedit restent ouverts et utilisables (persistance de la connexion via SFTP).

Comment faire en sorte que Nautilus restaure la connexion SFTP automatiquement?

La différence de comportement entre Gedit et Nautilus me surprend car tous les deux devraient utiliser le même mount qui se trouve dans ~/.gvfs , mount qui est manifestement restauré puisque Gedit fonctionne...

Merci,

Olivier

  • # effet memoire

    Posté par  . Évalué à 5.

    AMHA la connexion est tombé aussi pour Gedit

    seulement tu ne le vois pas car gedit travaille avec une copie de ton fichier dans sa memoire, et ne va rouvrir le FTP que quand tu vas enregistrer le document ou quand tu vas vouloir en ouvrir un autre.

    • [^] # Re: effet memoire

      Posté par  . Évalué à 0.

      @NeoX : Merci pour l'info. Il semblerait donc que la connexion SFTP soit restaurée via Gedit lorsque je fais un save, par exemple.

      Mais ma question de base demeure: comment restaurer la connexion au wakeup pour que Nautilus continue à fonctionner?

      • [^] # Re: effet memoire

        Posté par  . Évalué à 2.

        en faisant un marque-page (favori) dans la colonne de gauche de nautilus.

        il suffit alors de cliquer dessus pour "remonter" le sftp

        • [^] # Re: effet memoire

          Posté par  . Évalué à 0.

          Les marques pages sont une solution, mais ça ne résout pas le problème. Toutes le fenêtres Nautilius s'étant fermées au wakeup, je dois relancer Nautilus, ré-ouvrir tous les onglets, etc... et ça prend du temps ...

      • [^] # Reponse Courte: Tu ne peut pas

        Posté par  (site web personnel) . Évalué à 1.

        Réponse longue: va sur le bugzilla de gnome, vérifie si le problème à été identifié et sinon ouvre un nouveau bug

        • [^] # Re: Reponse Courte: Tu ne peut pas

          Posté par  . Évalué à 0.

          Merci - Avant d'ouvrir un nouveau bug, je pensais que c'était un problème déjà connu: suis-je seul à accéder par SFTP à des serveurs distant et à ouvrir de nombreuses fenêtres Nautilus?

          A mon sens, c'est lié probablement aux protocoles SSH / Fuse. Je pensais utiliser quelque chose comme autossh. Des idées?

          • [^] # Re: Reponse Courte: Tu ne peut pas

            Posté par  . Évalué à 2.

            perso quand je met en veille prolongée (hibernation), c'est que je n'ai plus besoin d'etre connecté, donc ca ne me gene pas que les connections reseaux connectés se coupent (par opposition à l'imap ou au http qui fonctionne en mode "deconnecté")

            en effet, quand tu te mets en veille, ca coupe le reseau
            le serveur en fasse coupe alors ta connexion SSH/SFTP, et il faut donc la "relancer" apres le reveil.

            idealement autossh devrait pouvoir faire ca, mais je ne sais pas si tu peux monter des dossiers dans le GVFS avec autossh.

            au pire, tu pourras les monter dans /mnt ou /media, et ensuite faire simplement un raccourci/marque page dans nautilus.

            • [^] # Re: Reponse Courte: Tu ne peut pas

              Posté par  . Évalué à 0.

              Bon, merci pour vos commentaires.

              Dans mon cas, relancer toutes les connexions me prend trop de temps: j'ai souvent plusieurs dizaines d'onglets Nautilus ouverts, vers des répertoires distants difficiles à retrouver, et pas toujours les mêmes...

              En plus d' autossh, je vais tester un script dans /etc/pm/sleep.d pour remonter la connexion proprement lors du resume_from_suspend/hibernate.

              Je vais aussi creuser du côté serveur la variable ClientAliveInterval dans /etc/ssh/sshd_config

Suivre le flux des commentaires

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