search

haiwen / seafile-client

Seafile desktop client.
http://seafile.com
Apache License 2.0
471 stars 279 forks source link

[Feature request] Seafile exited unexpectedly when file-system is read-only #1188

Open Bjarno opened 5 years ago

Bjarno commented 5 years ago

Issue:

When the filesystem where .seafile-data is stored is read-only, the client applet crashes without any meaningful error message.

image

Console output doesn't help either...

[bjarno@bjarch ~]$ seafile-applet
lang = English, translation = (null), locale.name() = en_US

When I remount my filesystem with write-capabilities the error is gone and Seafile works without any issues.

Context:

I have a shared partition used by both Windows and Linux. I only use Seafile on Linux, but would still like to access my files on Windows. When Windows crashes or hibernates, the filesystem gets mounted as read-only by Linux (as a safety precaution). This does not produce any error messages for other applications as the only application making use of that partition is Seafile.

Solution:

Manually check for whether the important folders can be used for writing. If not, show a better error message instead of "Seafile exited unexpectedly". This would direct users into the source of the error, instead of users having to guess why Seafile isn't working.

For example, an error message like "Seafile couldn't start due to the following errors: filesystem is read-only".

fuelflo commented 5 years ago

Sure that's the reason?

I have the same problem since a few days and the file-system where .seafile-data is stored is definitely mounted rw, also it's btrfs, so Linux only.

So might be something else. But I'm not sure how to troubleshoot without error messages.

bno1 commented 5 years ago

I'm having the same problem on a Linux-only machine with an ext4 file system. The file system is not read-only, but and it's stored on a separate drive than my root file system.

Bjarno commented 5 years ago

Sure that's the reason?

Rebooting such that the filesystem gets mounted as rw fixed the problem for me. Also, I can imagine that Seafile might have troubles doing just about anything if it can't write, so yes, that might explain it.

Why it doesn't work in your case(s), no idea. It might be related, it might not be. I haven't looked into it.

bno1 commented 5 years ago

I'm having the same problem on a Linux-only machine with an ext4 file system. The file system is not read-only, but and it's stored on a separate drive than my root file system.

So it appears that my problem is unrelated to this issue. I was checking out the log (~/.ccnet/logs/...) and I've seen that seafile-applet calls seaf-daemon. I tried invoking seaf-daemon myself and it gave me the following error:

seaf-daemon: error while loading shared libraries: libevent-2.1.so.6: cannot open shared object file: No such file or directory

I recompiled seafile (I'm on ArchLinux and seafile-client is an AUR package) and now it works. The logs didn't provide any directly useful information... you'd think they'd at least contain a trace or the stdout and stderr of whatever fails...

fuelflo commented 5 years ago

@bno1 yeah nice, did the same thing. Helped on ony of my PCs, on the second one I'll get

seaf-daemon: error while loading shared libraries: libevent-2.1.so.6: cannot open shared object file: No such file or directory

now every time I try to start seafile-applet. I rebuild several times, but no luck...mhm.

fengwang commented 5 years ago

Also this problem with my linux, but the log says:

[08/15/2019 01:45:41 PM]Seafile daemon process exited normally with code 127 [08/15/2019 01:45:41 PM]reaching max tries of restarting seafile daemon, aborting

fengwang commented 5 years ago

updating seafile to the same version with seafile-client solves my problem.

fuelflo commented 5 years ago

Just for info: https://aur.archlinux.org/packages/seafile/#comment-704490 fixed the libevent error seaf-daemon: error while loading shared libraries: libevent-2.1.so.6: cannot open shared object file: No such file or directory for me. Though it's just a workaround...

cpegel commented 5 years ago

@fuelflo Symlinking libevent-2.1.so.7 to libevent-2.1.so.6 is a bad workaround since you are now using Seafile with a libevent version it has not been linked against. Recompiling both the AUR packages seafile and seafile-client should fix the problem by linking against the installed version of libevent.

fuelflo commented 5 years ago

@rio- yeah thanks...I already thought that it's not the good way. But no matter how often I rebuild he seems to link against libevent-2.1-so.6 but the only libevent-2.1.so.6 I have on that PC is in a tor browser folder in my home directory (which, by the way, I also have on my other PC where seafile and seafile-client are linked against the correct library, without issues).

Do you have any Ideas how I could fix that?

cpegel commented 5 years ago

My best guess is that you are not properly rebuilding the two packages, but this isn't really the place to discuss distro specific package building.