gnome frozen when ssfhs stall

[Patrick Dupre]

Hello,

I already complained about the following issue, and I submitted the bug to bugzilla
without feedback.
If I have an open gnome session which turns to sleep because of a lack of
activity. Then, if a sshfs connection stalls, there is no way to relogin
through the gnome-session.

The only option that I have is to kill -9 -1 through a terminal tty
the gnome session, but I lost all the session.

Other options?

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================

[Roger Heflin]

In general if critical filesystems quit responding then everything
using them will hang.

Is critical files on the filesystem that gnome would need?  if it is
the home dir then it is critical.

An old trick with nfs was do not ever mount it directly on /, as the
pwd command works by checking all files in a dir until it finds .. and
then goes up and repeats the process, when it hits a mount in / that
is hung it stops.  So anything that happens to do a pwd will hang when
a mount in / is hung.  If you put it in say /machinename/mountname
then /machinename never hangs and pwd continues to work, so long as
nothing under /machinename is critical to gnome.  Lots of commands do
pwd for various things.

On Wed, Nov 27, 2019 at 3:01 AM Patrick Dupre <pdupre(a)gmx.com&gt; wrote:
>
> Hello,
>
> I already complained about the following issue, and I submitted the bug to bugzilla
> without feedback.
> If I have an open gnome session which turns to sleep because of a lack of
> activity. Then, if a sshfs connection stalls, there is no way to relogin
> through the gnome-session.
>
> The only option that I have is to kill -9 -1 through a terminal tty
> the gnome session, but I lost all the session.
>
> Other options?
>
> ===========================================================================
>  Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
>  Laboratoire interdisciplinaire Carnot de Bourgogne
>  9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
>  Tel: [phone]
> ===========================================================================
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Ed Greshko]

On 2019-11-27 17:00, Patrick Dupre wrote:
>  I already complained about the following issue, and I submitted the
> bug to bugzilla
>  without feedback.
>  If I have an open gnome session which turns to sleep because of a lack of
>  activity. Then, if a sshfs connection stalls, there is no way to relogin
>  through the gnome-session.
>
>  The only option that I have is to kill -9 -1 through a terminal tty
>  the gnome session, but I lost all the session.
>
>  Other options? 
What is the BZ number?

Is there a repeatable method to recreate?

-- 
The key to getting good answers is to ask good questions.

[Patrick Dupre]

Bug #
1731645

To reproduce the bug (fedora 30)
1) Create a sshfs on a remote machine from your home directory (sshfs
user@machine:/home/dir ~/SSHFS)
2) Lock the screen (I use gnome)
3) Unplug the internet cable of your machine for example (the connection stalls
pretty often with a ADSL connection)
4) Wait a minute and replug the cable
5) Try to log back in your gnome session.
After I enter the password, the time wheel froze and nothing happen anymore
You can log on the machine through a stty, and kill the gnome-session to have a new
graphic session.
After that it may happen that you cannot make the same sshfs again without restarting the
machine.

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================

>
> On 2019-11-27 17:00, Patrick Dupre wrote:
> > I already complained about the following issue, and I submitted the bug to
bugzilla
> > without feedback.
> > If I have an open gnome session which turns to sleep because of a lack of
> > activity. Then, if a sshfs connection stalls, there is no way to relogin
> > through the gnome-session.
> >
> > The only option that I have is to kill -9 -1 through a terminal tty
> > the gnome session, but I lost all the session.
> >
> > Other options?
> 
> What is the BZ number?
> 
> Is there a repeatable method to recreate?
> 
> -- 
> The key to getting good answers is to ask good questions.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Ed Greshko]

On 2019-11-28 19:27, Patrick Dupre wrote:
>  To reproduce the bug (fedora 30)
>  1) Create a sshfs on a remote machine from your home directory (sshfs
> user@machine:/home/dir ~/SSHFS)
>  2) Lock the screen (I use gnome)
>  3) Unplug the internet cable of your machine for example (the connection stalls
>  pretty often with a ADSL connection)
>  4) Wait a minute and replug the cable
>  5) Try to log back in your gnome session.
>  After I enter the password, the time wheel froze and nothing happen anymore
>  You can log on the machine through a stty, and kill the gnome-session to have a new
> graphic session.
>  After that it may happen that you cannot make the same sshfs again without restarting the
> machine. 
I do not have an F30 system available.  So, I tried, and was unable to reproduce this on
F31.  I have the
following.

An F31 system with GNOME running in a VM.

I mounted via sshfs the home directory on a system located in the USA.  I then locked the
screen.
I disconnected the link in the VM's GUI.  After more than a minute I reconnected the
nic.

I then entered my pw to unlock the screen and it unlocked immediately.  Additionally, the
sshfs
mount was still functional.

I was also able to unlock the screen with the NIC disconnected.  Of course something like
"df"
hung until (I didn't leave it hung long) the NIC is reconnected.

-- 
The key to getting good answers is to ask good questions.

[Patrick Dupre]

Good for you!

I made a mistake, in point 4). to be sure that is "work", you need to have the 
connection stalled. If you reconnect to early, the connection can be
re-established.

Hence, probably that you did not wait enough. The connection did to not have
the time to real stall because you reconnected the cable.
Just redo the same, but do not reconnect the cable before you try to
relogin.
Actually, when the connection is stalled, even with a tty terminal, a
ls command (of your home dir if the sshfs is in your homedir) must not be accomplished.

In my opinion the same thing happen under gnome, frozen the login.


===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Thursday, November 28, 2019 at 1:07 PM
> From: "Ed Greshko" <ed.greshko(a)greshko.com&gt;
> To: users(a)lists.fedoraproject.org
> Subject: Re: gnome frozen when ssfhs stall
>
> On 2019-11-28 19:27, Patrick Dupre wrote:
> > To reproduce the bug (fedora 30)
> > 1) Create a sshfs on a remote machine from your home directory (sshfs
user@machine:/home/dir ~/SSHFS)
> > 2) Lock the screen (I use gnome)
> > 3) Unplug the internet cable of your machine for example (the connection stalls
> > pretty often with a ADSL connection)
> > 4) Wait a minute and replug the cable
> > 5) Try to log back in your gnome session.
> > After I enter the password, the time wheel froze and nothing happen anymore
> > You can log on the machine through a stty, and kill the gnome-session to have a
new graphic session.
> > After that it may happen that you cannot make the same sshfs again without
restarting the machine.
> 
> I do not have an F30 system available.  So, I tried, and was unable to reproduce this
on F31.  I have the
> following.
> 
> An F31 system with GNOME running in a VM.
> 
> I mounted via sshfs the home directory on a system located in the USA.  I then locked
the screen.
> I disconnected the link in the VM's GUI.  After more than a minute I reconnected
the nic.
> 
> I then entered my pw to unlock the screen and it unlocked immediately.  Additionally,
the sshfs
> mount was still functional.
> 
> I was also able to unlock the screen with the NIC disconnected.  Of course something
like "df"
> hung until (I didn't leave it hung long) the NIC is reconnected.
> 
> -- 
> The key to getting good answers is to ask good questions.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Ed Greshko]

On 2019-11-28 21:24, Patrick Dupre wrote:
>  I made a mistake, in point 4). to be sure that is "work",
> you need to have the 
>  connection stalled. If you reconnect to early, the connection can be
>  re-established.
>
>  Hence, probably that you did not wait enough. The connection did to not have
>  the time to real stall because you reconnected the cable.
>  Just redo the same, but do not reconnect the cable before you try to
>  relogin.
>  Actually, when the connection is stalled, even with a tty terminal, a
>  ls command (of your home dir if the sshfs is in your homedir) must not be accomplished.
>
>  In my opinion the same thing happen under gnome, frozen the login. 
I just retested.  I waited 5 minutes after disabling the NIC before enabling it again.

No problem.  I was able to unlock the screen and the mount was maintained.

Is 5 minutes not long enough?

-- 
The key to getting good answers is to ask good questions.

[Patrick Dupre]

But, just try to login when the cable is off.
If you have a network of good quality, when you replug the cable
to recover the connection easily.
With a DSL connection, the network stalls periodically, and then does not
recover.

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Thursday, November 28, 2019 at 2:54 PM
> From: "Ed Greshko" <ed.greshko(a)greshko.com&gt;
> To: users(a)lists.fedoraproject.org
> Subject: Re: gnome frozen when ssfhs stall
>
> On 2019-11-28 21:24, Patrick Dupre wrote:
> > I made a mistake, in point 4). to be sure that is "work", you need to
have the 
> > connection stalled. If you reconnect to early, the connection can be
> > re-established.
> >
> > Hence, probably that you did not wait enough. The connection did to not have
> > the time to real stall because you reconnected the cable.
> > Just redo the same, but do not reconnect the cable before you try to
> > relogin.
> > Actually, when the connection is stalled, even with a tty terminal, a
> > ls command (of your home dir if the sshfs is in your homedir) must not be
accomplished.
> >
> > In my opinion the same thing happen under gnome, frozen the login.
> 
> I just retested.  I waited 5 minutes after disabling the NIC before enabling it
again.
> 
> No problem.  I was able to unlock the screen and the mount was maintained.
> 
> Is 5 minutes not long enough?
> 
> -- 
> The key to getting good answers is to ask good questions.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Ed Greshko]

On 2019-11-28 22:00, Patrick Dupre wrote:
>  But, just try to login when the cable is off.
>  If you have a network of good quality, when you replug the cable
>  to recover the connection easily.
>  With a DSL connection, the network stalls periodically, and then does not
>  recover. 
I locked the screen, disconnected the VM from the network, waited 5 minutes, and was able
to unlock the screen without difficulty with the network disconnected.

As expected, some commands which require access to the mounted partition would hang.
But they would un-hang soon at the network was reconnected.


-- 
The key to getting good answers is to ask good questions.

[Patrick Dupre]

>  Sent: Thursday, November 28, 2019 at 3:25 PM
>  From: "Ed Greshko" <ed.greshko(a)greshko.com&gt;
>  To: users(a)lists.fedoraproject.org
>  Subject: Re: gnome frozen when ssfhs stall
>
>  On 2019-11-28 22:00, Patrick Dupre wrote:
>  > But, just try to login when the cable is off.
>  > If you have a network of good quality, when you replug the cable
>  > to recover the connection easily.
>  > With a DSL connection, the network stalls periodically, and then does not
>  > recover.
>
>  I locked the screen, disconnected the VM from the network, waited 5 minutes, and was
> able
>  to unlock the screen without difficulty with the network disconnected.
>
>  As expected, some commands which require access to the mounted partition would hang.
>  But they would un-hang soon at the network was reconnected. 
Yes, probably, but if
the network is never back correctly (time out, or
"bad" network), then, it never recovers.

>
>
> --
> The key to getting good answers is to ask good questions.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Ed Greshko]

On 2019-11-28 22:39, Patrick Dupre wrote:
>  Yes, probably, but if the network is never back correctly (time out,
> or
>  "bad" network), then, it never recovers. 
FWIW, I locked the screen and disconnected the network at 01:52.  Then at 06:01 I
reconnected
the network.  I then was able to unlock the screen and even after 4hrs the sshfs mount
was
still live.


-- 
The key to getting good answers is to ask good questions.

Hi.

On Thu, 28 Nov 2019 12:27:53 +0100 "Patrick Dupre" wrote:

>  To reproduce the bug (fedora 30) 
>  1) Create a sshfs on a remote machine from your home directory
>   (sshfs user@machine:/home/dir ~/SSHFS) 
Using a subdir of your homedir as a network mountpoint if risky.

Roger Heflin indicated that in this post:

 
https://lists.fedoraproject.org/archives/list/[e-mail].o...

Can you try to mount it for exxample on:

  $XDG_RUNTIME_DIR/net/SSHFS (ie: /run/user/YOUR_UNIX_UID/net/SSHFS)

and do not make a symlink ~/SSHFS -> $XDG_RUNTIME_DIR/net/SSHFS

A symlink ~/net -> $XDG_RUNTIME_DIR/net should be harmless.

-- 
francis

[Roger Heflin]

Broken links return immediately and don't hang.  on Production systems
the symlink to /mnt/nfsfs from wherever it needs to look like it is at
correctly allows pwd to work when the filesystem it is pointing at is
not responding.

On Sun, Dec 8, 2019 at 2:31 PM Patrick Dupre <pdupre(a)gmx.com&gt; wrote:
>
> Thank for the suggestion.
>
> Actually, I did the ssh mount in /mnt which avoids the mentioned issue.
> However, I am reluctant to put a symbolic link on this directory, because
> a ln on a "broken" link will probably generate the same issue.
>
>
> >
> > Hi.
> >
> > On Thu, 28 Nov 2019 12:27:53 +0100 "Patrick Dupre" wrote:
> >
> > > To reproduce the bug (fedora 30)
> >
> > > 1) Create a sshfs on a remote machine from your home directory
> > > (sshfs user@machine:/home/dir ~/SSHFS)
> >
> > Using a subdir of your homedir as a network mountpoint if risky.
> >
> > Roger Heflin indicated that in this post:
> >
> >
https://lists.fedoraproject.org/archives/list/[e-mail].o...
> >
> > Can you try to mount it for exxample on:
> >
> > $XDG_RUNTIME_DIR/net/SSHFS (ie: /run/user/YOUR_UNIX_UID/net/SSHFS)
> >
> > and do not make a symlink ~/SSHFS -> $XDG_RUNTIME_DIR/net/SSHFS
> >
> > A symlink ~/net -> $XDG_RUNTIME_DIR/net should be harmless.
> >
> > --
> > francis
> > _______________________________________________
> > users mailing list -- users(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> >
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]