SUMMARY If I have a file open in Gwenview, where the file is from an sftp mount, and I wake up the Laptop from sleep, it can freeze both Gwenview and all of Plasma, requiring a hard reboot via power button. STEPS TO REPRODUCE 1. Mount a remote filesystem in Dolphin as a FUSE mount (i.e., a path starting with sft://) 2. From the mounted location in Dolphin, double click a png file to open it in Gwenview 3. Put laptop to sleep for a long time (e.g. overnight, often shorter) 4. Wake up laptop from sleep and log in to user account OBSERVED RESULT Gwenview window is "not responding". Trying to end gwenview, even with "sudo kill -9 <pid>" form command line doesn't do anything. Shortly after that, items in the dock become unresponsive upon click. One can sometimes still navigate between apps with Alt-Tab, and other apps still work. Shortly after that, other apps also freeze and the entire computer becomes unresponsive. Sometimes there's also visual glithiness (see attached image). EXPECTED RESULT Can still browse images in Gwenview as normal (best case), can force-quit gwenview (good workaround), Plasma doesn't become unresponsive (bare minimum) SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.8.0-40-generic (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz Memory: 30.8 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 630 ADDITIONAL INFORMATION I don't know exactly how to get good logs, but I extracted a log from systemd "journalctl" after a reboot. Apparently I cant make more than one attachment in one go in this bug description, so I'll attach it after. Also, when I checked htop, I saw that gwenview had opened a path that had "kio-fuse" in it, that's why I'm filing this at the kio-fuse component.
Created attachment 173582 [details] visual glitch in gwenview window
Created attachment 173583 [details] systemd log
> 1. Mount a remote filesystem in Dolphin as a FUSE mount (i.e., a path starting with sft://) > 2. From the mounted location in Dolphin, double click a png file to open it in Gwenview Hm. If you just open an sftp:// location in Dolphin and open a file within with gwenview, it should pass the sftp:// URL directly. If not that's a bug on its own IMO. In any case, this shouldn't happen, at least after some time the request should time out. Can you still navigate to the kio-fuse mount with dolphin?
> Hm. If you just open an sftp:// location in Dolphin and open a file within with gwenview, > it should pass the sftp:// URL directly. If not that's a bug on its own IMO. I believe that *is* actually what's happening! My understanding of mounting, fuse, sftp etc. is very limited. What part of what I said made you think that this isnt what's happening (honest question)? In htop, this is how the gwenview process gets displayed: /usr/bin/gwenview /run/user/1000/kio-fuse-ziyHkE/sftp/malte@redacted:22/home/malte/xxx.png > Can you still navigate to the kio-fuse mount with dolphin? Do you mean that if I still have a dolphin window open with the mounted folder open, can I still navigate within its hierarchy? That maybe not, not 100% sure. But if I click in the side-panel on the entry with the remote location, it will immediately load. I think the remote folder gets mounted via ssh somehow, probably sshfs? I don't remember how it was set up, but mounting only works after I added ssh-keys to the ssh-agent.
(In reply to git from comment #4) > > Hm. If you just open an sftp:// location in Dolphin and open a file within with gwenview, > > it should pass the sftp:// URL directly. If not that's a bug on its own IMO. > I believe that *is* actually what's happening! My understanding of mounting, > fuse, sftp etc. is very limited. What part of what I said made you think > that this isnt what's happening (honest question)? gwenview supports sftp:// on its own, it doesn't need kio-fuse. > In htop, this is how the gwenview process gets displayed: > > /usr/bin/gwenview > /run/user/1000/kio-fuse-ziyHkE/sftp/malte@redacted:22/home/malte/xxx.png Ok, that shouln't be needed. Can you try to reproduce the issue with this? gwenview sftp://malte@redacted:22/home/malte/xxx.png > > Can you still navigate to the kio-fuse mount with dolphin? > > Do you mean that if I still have a dolphin window open with the mounted > folder open, can I still navigate within its hierarchy? Yes. > That maybe not, not > 100% sure. But if I click in the side-panel on the entry with the remote > location, it will immediately load. And files can still be opened with gwenview? Does the builtin terminal widget work (it uses kio-fuse)? I wonder whether it's an issue with the opened file specifically or the sftp connection. > I think the remote folder gets mounted via ssh somehow, probably sshfs? I > don't remember how it was set up, but mounting only works after I added > ssh-keys to the ssh-agent. Yes, sftp:// works through ssh.
> Ok, that shouln't be needed. Can you try to reproduce the issue with this? > gwenview sftp://malte@redacted:22/home/malte/xxx.png I can definitely open the image just fine with this command. I'm trying to reproduce the issue now. However, to do this, basically now I have to keep gwenview open and put the laptop to sleep for "long enough". My hypothesis is that this "long enough" is because if the laptop is asleep long enough, then the ssh connection for sshfs somehow gets interrupted, and only then the issue occurs. I haven't figured out yet exactly how long this takes. I wonder if I could somehow mess with the sshfs connection directly to speed up the debugging process.
I tested overnight to leave a process gwenview sftp://malte@redacted:22/home/malte/xxx.png running. Result: no problem, I could even continue browsing images. Then, I opened another gwenview by opening an image from dolphin (as I did when I originally created this issue). The process was of this type: /usr/bin/gwenview /run/user/1000/kio-fuse-ziyHkE/sftp/malte@redacted:22/home/malte/xxx.png After putting the laptop to sleep for around 2 hours, only one gwenview had frozen. The latter. When I tried to kill it, even with `sudo kill -9 <pid>`, it didn't work, and Plasma itself started freezing.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
I'm a bit disappointed that this was just closed, as I had in fact provided further details. But I won't push this further. I could imagine it's a gwenview-specific issue anyways.
> I'm a bit disappointed that this was just closed, as I had in fact provided further details. It was closed because you didn't set the bug status after providing info. I already reopened it.
Ah, I'm sorry for my previous message then! Should we take another look at this? As I said, it may be gwenview-specific. At least, Dolphin doesn't have a problem with the kio-fuse connection stopping, only gwenview.
> Should we take another look at this? As I said, it may be gwenview-specific. I suspect it's the handle to the file opened by gwenview that causes the hang. Dolphin doesn't keep file handles open (to my knowledge) so wouldn't be affected by this. I'm also wondering why gwenview uses the kio-fuse URL instead of sftp:// directly. That could be a gwenview or kio bug. You could try running kio-fuse with QT_LOGGING_RULES=*.debug=true /usr/libexec/kio-fuse -d (you might have to stop kio-fuse first and the path might vary by distro) and reproducing the issue. With some luck there's some indication of the cause visible. At least the stuck call from gwenview should appear as request without reply.