SeaDrive Transport Endpoint is not connected

After closing SeaDrive the SeaDrive folder is not removed and when accessing it the error “Transport Endpoint is not connected” occurs.

The SeaDrive folder in 2.0 version is a physical folder in the file system. So all the cached files and the folder will remain when SeaDrive is not running. OneDrive works the same way. But I didn’t experience the “Transport Endpoint is not connected” error. You should still be able to access the folder (C:\users\username\SeaDrive\seafile-username)

Sorry, it is on Linux. The folder cannot be accessed.

Can you reproduce this issue? Or just had it once? Which OS do you use?

I’m using Fedora 33. The issue is reproducible. Start SeaDrive, the SeaDrive folder appears. Stop SeaDrive the folder is there, but accessing it leads to the fault. Expected behavior would be that the SeaDrive folder disappears on stop to not have any errors when using ls or other tools doing recursive lookups in the home folder (for example disk usage analyzer).

~ ls -l | grep SeaD
ls: cannot access 'SeaDrive': Transport endpoint is not connected
d??????????  ? ?       ?            ?            ? SeaDrive

You can use the following command to fix:

~ sudo umount ./SeaDrive

The reason should be that the program is forced to exit without umount SeaDrive folder.

The program was exited using the SeaDrive tray icon.

Manually unmounting works (thought I tried that without success, last time. But tried it again and it worked). Still, I think SeaDrive should do that on exit.

It usually should unmount the drive on exit. Maybe you can find something in seadrive.log or seadrive-gui.log?

Here is the tail of seadrive-gui.log after reproducing the issue:

[12/10/2020 05:55:21 PM] app event loop exited with 0

[12/10/2020 05:55:21 PM] Unmounting before exit
[12/10/2020 05:55:21 PM] [Daemon Mgr] stopping seadrive daemon
[12/10/2020 05:55:21 PM] Seadrive daemon process crashed with code 9

Code 9 is suspiciously familiar, so I opened seadrive-gui/src/daemon-mgr.cpp and scrolled to the daemon termination function. Appears that it’s calling QProcess::kill and sends SIGKILL to the daemon, making it skip any cleanup code and exit immediately.

It’s interesting that the gui is actually sending unmount rpc command to the daemon process before killing it, but seafile_unmount is noop on Linux because fuse_main is expected to do that during graceful termination.

With the following change I’m getting Seadrive daemon process exited normally with code 0 and no stale fuse mounts.
I haven’t checked how that affects behavior on Mac OS due to lack of Mac devices :slight_smile:

diff --git a/src/daemon-mgr.cpp b/src/daemon-mgr.cpp
index 47be92b..f7236ae 100644
--- a/src/daemon-mgr.cpp
+++ b/src/daemon-mgr.cpp
@@ -310,7 +310,7 @@ void DaemonManager::stopAllDaemon()
             qWarning("failed to exit seadrive daemon");
         }
 #else
-        seadrive_daemon_->kill();
+        seadrive_daemon_->terminate();
 #endif
         seadrive_daemon_->waitForFinished(1500);
         conn_daemon_timer_ = nullptr;
2 Likes

@alebastr After looking at the code, it’s not related to the kill method. It’s that the mount point is intentionally not unmounted on exit. I don’t remember why is the decision when the code was written. We’ll see whether it can be unmounted.

Ah, I’ve seen the comment about intentionally ignoring unmount rpc command, but I thought it’s not related to this issue.

It’s just that fuse_main always unmounts filesystem during clean exit and killing daemon process with SIGKILL is an odd way to prevent that. That part didn’t look intentional to me, esp. because mount point would be unmounted on exit when seadrive daemon is used without gui :slight_smile: