Arch Linux User Repository

@bionade24 The strange thing is that the library has been created a couple of months ago, and everything worked up to this morning, with a manual sync operation performed every day. So if "two months ago" is recent enough to make it a "new, actually secure library" and thus without password then probably there never were entries in RepoPasswd, and still everything worked. If this is true then the lack of entries in RepoPasswd is not the cause of the problem.

I'll open the issue on GitHub.

Edit: https://github.com/haiwen/seafile/issues/2662

@snack: No, there shouldn't be one for the new, actually secure library types, like I already said in the last sentence.

It can only crash if something (e.g. a file attribute) of in the library folder changes, otherwise the repo is the same & no sync update is triggered.

I think you should open an issue on GH for this.

Well. the library is just a backup of one local folder. I will simply remove and re-create it, and see if this fixes the problem. Still I don't understand why it worked until yesterday and then today it stopped working, since there was no seafile update in the middle.

Edit: actually there's no entry in the RepoPasswd table of repo.db. Could this be the problem? If yes, I really don't understand why it vanished since this morning.

@snack You're right, I should have looked closer. From a quick look at the code, encrypted libaries on the latest version shouldn't store the password locally, only the derived key. Do you maybe have a very old encrypted library. Anyway, if you want to investigate further, you can start at add_task_common(), your passwd arg has already is 0 there. Maybe you can also check if you have any password still stored in repo.db. I don't, even though I have encrypted libraries.

As I guessed by looking at the gdb trace below, the issue is with the passwd argument of seafile_decrypt_repo_enc_key being NULL. Indeed, line 239 of common/seafile-crypt.c is:

seafile_derive_key (passwd, strlen(passwd), enc_version, repo_salt, key, iv);

and after installing the glibc-debug package (debuginfod didn't work) the gdb trace shows:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
76              VPCMPEQ (%rdi), %ymm0, %ymm1

So I think that the segfault comes from the call to strlen(passwd) with passwd being NULL.

@snack You need to install & activate https://wiki.archlinux.org/title/Debuginfod to get debug symbols for the libraries that seafile-daemon uses. Then you can try run the same coredumpctl cmd again, but this time there should be proper function names instead of ()

After months of working with no problem the issue with seaf-daemon crashing on start happened again this morning. I paste below the debug output. @bionade24 do you see anything useful in it?

Edit: I forgot to mention that I freshly rebuilt libsearpc, seafile and seafile-applet before doing the test.

$ sudo coredumpctl debug seaf-daemon
           PID: 66561 (seaf-daemon)
           UID: 10085 (mori)
           GID: 1014 (wizard)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-03-29 11:15:50 CEST (38s ago)
  Command Line: /usr/bin/seaf-daemon -c /home/mori/.ccnet -d /home/mori/Seafile/.seafile-data -w /home/mori/Seafile
    Executable: /usr/bin/seaf-daemon
 Control Group: /user.slice/user-10085.slice/user@10085.service/app.slice/app-seafile-c6e8b7676597445f85bfd3f4137af75c.scope
          Unit: user@10085.service
     User Unit: app-seafile-c6e8b7676597445f85bfd3f4137af75c.scope
         Slice: user-10085.slice
     Owner UID: 10085 (mori)
       Boot ID: 3c7622accfcb48e3a2ad3c65a9ebbba0
    Machine ID: cce5ac542ac74861bed9479dcf1d5978
      Hostname: stryke
       Storage: /var/lib/systemd/coredump/core.seaf-daemon.10085.3c7622accfcb48e3a2ad3c65a9ebbba0.66561.1680081350000000.zst (present)
  Size on Disk: 3.4M
       Message: Process 66561 (seaf-daemon) of user 10085 dumped core.

                Stack trace of thread 66567:
                #0  0x00007f5ab6a1235d n/a (libc.so.6 + 0x15635d)
                #1  0x000055918c2abc4b seafile_decrypt_repo_enc_key (seaf-daemon + 0x20c4b)
                #2  0x000055918c2c0571 seaf_repo_fetch_and_checkout (seaf-daemon + 0x35571)
                #3  0x000055918c2a1eeb http_download_thread (seaf-daemon + 0x16eeb)
                #4  0x000055918c29a67b job_thread_wrapper (seaf-daemon + 0xf67b)
                #5  0x00007f5ab6c8e9a3 n/a (libglib-2.0.so.0 + 0x8c9a3)
                #6  0x00007f5ab6c89315 n/a (libglib-2.0.so.0 + 0x87315)
                #7  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #8  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66566:
                #0  0x00007f5ab6988db5 clock_nanosleep (libc.so.6 + 0xccdb5)
                #1  0x00007f5ab698d987 __nanosleep (libc.so.6 + 0xd1987)
                #2  0x00007f5ab6c870b1 g_usleep (libglib-2.0.so.0 + 0x850b1)
                #3  0x000055918c2b9c93 cleanup_deleted_stores (seaf-daemon + 0x2ec93)
                #4  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #5  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66574:
                #0  0x00007f5ab69b296c read (libc.so.6 + 0xf696c)
                #1  0x00007f5ab726c58f n/a (libsearpc.so.1 + 0x758f)
                #2  0x00007f5ab726c71a n/a (libsearpc.so.1 + 0x771a)
                #3  0x00007f5ab726cab9 n/a (libsearpc.so.1 + 0x7ab9)
                #4  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #5  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66572:
                #0  0x00007f5ab69b296c read (libc.so.6 + 0xf696c)
                #1  0x00007f5ab726c58f n/a (libsearpc.so.1 + 0x758f)
                #2  0x00007f5ab726c71a n/a (libsearpc.so.1 + 0x771a)
                #3  0x00007f5ab726cab9 n/a (libsearpc.so.1 + 0x7ab9)
                #4  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #5  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66576:
                #0  0x00007f5ab69bc0dd syscall (libc.so.6 + 0x1000dd)
                #1  0x00007f5ab6cb2d03 g_cond_wait_until (libglib-2.0.so.0 + 0xb0d03)
                #2  0x00007f5ab6c26f83 n/a (libglib-2.0.so.0 + 0x24f83)
                #3  0x00007f5ab6c8e9fb n/a (libglib-2.0.so.0 + 0x8c9fb)
                #4  0x00007f5ab6c89315 n/a (libglib-2.0.so.0 + 0x87315)
                #5  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #6  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66562:
                #0  0x00007f5ab69bc0dd syscall (libc.so.6 + 0x1000dd)
                #1  0x00007f5ab6cb27b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
                #2  0x00007f5ab6c26fb4 n/a (libglib-2.0.so.0 + 0x24fb4)
                #3  0x00007f5ab6c8df9e n/a (libglib-2.0.so.0 + 0x8bf9e)
                #4  0x00007f5ab6c89315 n/a (libglib-2.0.so.0 + 0x87315)
                #5  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #6  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66561:
                #0  0x00007f5ab69c41b6 epoll_wait (libc.so.6 + 0x1081b6)
                #1  0x00007f5ab6dd4d03 n/a (libevent-2.1.so.7 + 0x26d03)
                #2  0x00007f5ab6dd2195 event_base_loop (libevent-2.1.so.7 + 0x24195)
                #3  0x000055918c293a87 main (seaf-daemon + 0x8a87)
                #4  0x00007f5ab68df790 n/a (libc.so.6 + 0x23790)
                #5  0x00007f5ab68df84a __libc_start_main (libc.so.6 + 0x2384a)
                #6  0x000055918c293c35 _start (seaf-daemon + 0x8c35)

                Stack trace of thread 66565:
                #0  0x00007f5ab6988db5 clock_nanosleep (libc.so.6 + 0xccdb5)
                #1  0x00007f5ab698d987 __nanosleep (libc.so.6 + 0xd1987)
                #2  0x00007f5ab6c870b1 g_usleep (libglib-2.0.so.0 + 0x850b1)
                #3  0x000055918c2a545b update_cached_head_commit_ids (seaf-daemon + 0x1a45b)
                #4  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #5  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66575:
                #0  0x00007f5ab69b296c read (libc.so.6 + 0xf696c)
                #1  0x00007f5ab726c58f n/a (libsearpc.so.1 + 0x758f)
                #2  0x00007f5ab726c71a n/a (libsearpc.so.1 + 0x771a)
                #3  0x00007f5ab726cab9 n/a (libsearpc.so.1 + 0x7ab9)
                #4  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #5  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66564:
                #0  0x00007f5ab69c58bf accept (libc.so.6 + 0x1098bf)
                #1  0x00007f5ab726c633 n/a (libsearpc.so.1 + 0x7633)
                #2  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #3  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66573:
                #0  0x00007f5ab69b296c read (libc.so.6 + 0xf696c)
                #1  0x00007f5ab726c58f n/a (libsearpc.so.1 + 0x758f)
                #2  0x00007f5ab726c71a n/a (libsearpc.so.1 + 0x771a)
                #3  0x00007f5ab726cab9 n/a (libsearpc.so.1 + 0x7ab9)
                #4  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #5  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)

                Stack trace of thread 66563:
                #0  0x00007f5ab69b91cc __select (libc.so.6 + 0xfd1cc)
                #1  0x000055918c2ae47c wt_monitor_job_linux (seaf-daemon + 0x2347c)
                #2  0x000055918c29a67b job_thread_wrapper (seaf-daemon + 0xf67b)
                #3  0x00007f5ab6c8e9a3 n/a (libglib-2.0.so.0 + 0x8c9a3)
                #4  0x00007f5ab6c89315 n/a (libglib-2.0.so.0 + 0x87315)
                #5  0x00007f5ab6941bb5 n/a (libc.so.6 + 0x85bb5)
                #6  0x00007f5ab69c3d90 n/a (libc.so.6 + 0x107d90)
                ELF object binary architecture: AMD x86-64

GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/seaf-daemon...
[New LWP 66567]
[New LWP 66566]
[New LWP 66574]
[New LWP 66572]
[New LWP 66576]
[New LWP 66562]
[New LWP 66561]
[New LWP 66565]
[New LWP 66575]
[New LWP 66564]
[New LWP 66573]
[New LWP 66563]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/seaf-daemon -c /home/mori/.ccnet -d /home/mori/Seafile/.seafile-data -'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5ab6a1235d in ?? () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f5aaf7fe6c0 (LWP 66567))]
(gdb) bt
#0  0x00007f5ab6a1235d in  () at /usr/lib/libc.so.6
#1  0x000055918c2abc4b in seafile_decrypt_repo_enc_key
    (enc_version=2, passwd=passwd@entry=0x0, random_key=0x7f5a9c1310c0 "ec595ae994a7551cd5d873c34d1f5f7c518fa10f1cfb6ff0418fb65ef59208776a3cf5263fd0e99bb9bfd4e81c947dc8", repo_salt=0x0, key_out=key_out@entry=0x7f5aaf7fcc20 "787ddc6a83ef11edacfcd83c1a4dd5d2a821c825", iv_out=iv_out@entry=0x7f5aaf7fcbf0 "la.mori@fi.infn.it\", \"mtime\": 1376768269, \"name\"787ddc6a83ef11edacfcd83c1a4dd5d2a821c825") at ../common/seafile-crypt.c:239
#2  0x000055918c2c0571 in seaf_repo_fetch_and_checkout (http_task=http_task@entry=0x55918e364080, remote_head_id=remote_head_id@entry=0x55918e3640ec "add1215edd063a1caeae54b028566e44b3b8145f") at repo-mgr.c:5853
#3  0x000055918c2a1eeb in http_download_thread (vdata=0x55918e364080) at http-tx-mgr.c:4883
#4  0x000055918c29a67b in job_thread_wrapper (vdata=0x55918e364320, unused=<optimized out>) at job-mgr.c:66
#5  0x00007f5ab6c8e9a3 in  () at /usr/lib/libglib-2.0.so.0
#6  0x00007f5ab6c89315 in  () at /usr/lib/libglib-2.0.so.0
#7  0x00007f5ab6941bb5 in  () at /usr/lib/libc.so.6
#8  0x00007f5ab69c3d90 in  () at /usr/lib/libc.so.6
(gdb) 

@snack: Rebuild the package with debug symbols and if it afterwards crashes again, run coredumpctl debug seafile-daemon and then bt and post the output here. This will help much more than asking if others have the same issue. https://wiki.archlinux.org/title/Debugging/Getting_traces#Rebuild_packages

Since version 8.0.10 I get a strange behavior. After upgrade to 8.0.10 everything seemed to work correctly, but after a restart of seafile-applet none of my libraries was synced anymore. This is due to seaf-daemon continuously segfaulting. I had to delete ~/Seafile/, restart seafile-applet and re-sync everything. But after another restart of seafile-applet the problem came up again. I downgraded to 8.0.9 and now everything seems OK again.

It looks like seaf-daemon 8.0.10 has a bug that makes it mess with something on shutdown, which in turn makes it segfault at the subsequent restart, and that it works only with a pristine configuration. Does anybody experience the same?