New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
seaf-daemon crashing because of missing password #2662
Comments
I have been able to make it work again by removing |
Hello @nicolamori , can you show the seafile.log output when the crash occurs ? |
Where can I find it? I can't find it in |
@nicolamori Under |
This is an excerpt from the log file during several crash and restart:
|
Hi @nicolamori , the crash occurred when the library was downloaded for the first time, can you take a look at the records in the |
Here it is:
|
Hello @nicolamori, there is no password in this table, which will cause this crash. We will add a check for password in next release. |
@feiniks Ok, thank you. Have you got any idea why this problem suddenly happened? As I wrote, everything worked up to the previous day, and nothing changed in my system (i.e. no upgrades) before the issue came up. |
@feiniks It just happened again. The password seems to be missing again from the clone.db:
Is it possible to repair the entry? If yes, can you provide some info about how to do that? Thank you. Edit: I removed the entry and restarted the client. This fixes the daemon segfault but leaves the library unsynced, so I had to re-sync from scratch, deal with conflicts etc. From inspecting the clone.db during the sync I see that the password must be inserted in clear text in the field after the local path (/home/mori/.config in the above case). This makes me think that the problem stems from the library somehow becoming unsynced and in the middle of a sync. I really don't understand what's happening but I hope this information can be useful for the devs. |
Hello @nicolamori Deleting the row in the database, then resyncing the library should fix the issue. As for why the password here is empty, I checked the parameters passed in during gui synchronization, but I didn't find the possible reason for this problem. Did you enter the encrypted library password through the gui? |
@feiniks Yes I do everything through the GUI. Why after deleting the row I had to re-sync from scratch? Yesterday the library was synced and working beautifully, so whatever happens makes me I end up with a non-synced library. If this might be useful, I disable the automatic sync for the library and manually sync it once per day. I didn't notice if the problem raises because of manual sync, but for sure almost always manual sync simply worked. |
@feiniks The problem happened again, but this time I paid attention to what was happening. After booting my pc I manually launched a sync for the library. I got a dialog message asking me if I wanted to delete a SFConflict file plus many others (~15k files). I refused, and the library display in the GUI showed something like "Waiting for file deletion confirmation". I checked the local folder and no SFConflict file was present, so I tried again to sync manually. At this point the GUI displayed something like "Downolading files list", the same sentence displayed when syncyng a library from scratch. At the end of the download the daemon started to crash repeatedly, and the entry in This time I repaired the entry in Hope this helps, I can do other tests if needed. By the way, I have another library that I manually sync, but it never gave this problem; although I always sync it after the troublesome one and so it could just be that the first manually synced triggers the problem, this could point towards a problem with the library itself. |
@nicolamori Thank you for your feedback. I think I know where the problem is. It should be caused by not passing in a password when re-sync the encrypted library during the deletion confirmation process. I will fix this problem in the next release. |
@feiniks It happened again with 9.0.1. I didn't expect this since you wrote that you would fix the problem in the "next release", and at that time I was on 8.0.10. Maybe the fix wasn't included in 9.0.1? If yes, in which version do you plan to include it? |
The next release is 9.0.2 |
Since this morning seaf-daemon segfaults on my system (Archlinux). In my setup I have several libraries, some of them are encrypted. The libraries have been created on the server a couple of years ago, and the client has been set up two months ago with seafile-client 8.0.10 (which I'm still using at the moment). Everything worked flawlessly until this morning; no modification of the seafile installation has been performed in the meantime.
Investigating the crash with gdb I got the following:
Inspecting the line 239 of
common/seafile-crypt.c
I see there's a call tostrlen(passwd)
, which is probably the cause of the segfault since as shown abovepasswd
is NULL and the actual segfault is in__strlen_avx2
inside glibc. I checked~/Seafile/.seafile-data/repo.db
and I see no entries in theRepoPasswd
table, but I don't know if this can be related/relevant.I don't know which other info could be useful, but I can provide it if needed.
The text was updated successfully, but these errors were encountered: