seafile-applet exited unexpectedly due to SQL error: duplicate column name: commit_id

[troiganto]

Hi, I run Seafile as a flatpak on Fedora Silverblue, currently v9.0.6, but I've tested a locally built v9.0.7 as well.

For a while now, whenever I try to open the GUI applet, I only get a message box that says "Seafile has exited unexpectedly". I've had a lookt at ~/.ccnet/logs/applet.log and this is the output it produces:

[09.08.2024 10:16:07]read id from id file (/run/build/seafile-client/src/seafile-applet.cpp:830)
[09.08.2024 10:16:07]client id is 84a94c454d2ce9f88989e2fca1639f32c97dee3b (/run/build/seafile-client/src/seafile-applet.cpp:251)
[09.08.2024 10:16:07]SQL error: 1 - duplicate column name: commit_id
:   ALTER TABLE FileCacheV2 ADD COLUMN commit_id TEXT
[09.08.2024 10:16:07]starting seaf-daemon:  ("-c", "~/.ccnet", "-d", "~/Seafile/.seafile-data", "-w", "~/Seafile") (/run/build/seafile-client/src/daemon-mgr.cpp:120)
[09.08.2024 10:16:07]daemon mgr: init => starting (/run/build/seafile-client/src/daemon-mgr.cpp:213)
[09.08.2024 10:16:07]seafile daemon is now running, checking if the service is ready (/run/build/seafile-client/src/daemon-mgr.cpp:131)
[09.08.2024 10:16:07]daemon mgr: starting => connecting (/run/build/seafile-client/src/daemon-mgr.cpp:213)
[09.08.2024 10:16:07]Seafile daemon process exited normally with code 1  (/run/build/seafile-client/src/daemon-mgr.cpp:164)
[09.08.2024 10:16:09]Trying to restart seafile daemon (/run/build/seafile-client/src/daemon-mgr.cpp:98)
[09.08.2024 10:16:09]starting seaf-daemon:  ("-c", "~/.ccnet", "-d", "~/Seafile/.seafile-data", "-w", "~/Seafile") (/run/build/seafile-client/src/daemon-mgr.cpp:120)
[09.08.2024 10:16:09]daemon mgr: connecting => starting (/run/build/seafile-client/src/daemon-mgr.cpp:213)
[09.08.2024 10:16:09]seafile daemon is now running, checking if the service is ready (/run/build/seafile-client/src/daemon-mgr.cpp:131)
[09.08.2024 10:16:09]daemon mgr: starting => connecting (/run/build/seafile-client/src/daemon-mgr.cpp:213)
[09.08.2024 10:16:09]Seafile daemon process exited normally with code 1  (/run/build/seafile-client/src/daemon-mgr.cpp:164)
[09.08.2024 10:16:09]reaching max tries of restarting seafile daemon, aborting (/run/build/seafile-client/src/daemon-mgr.cpp:204)
[09.08.2024 10:16:10]Seafile ist unerwartet abgebrochen (/run/build/seafile-client/src/seafile-applet.cpp:540)
[09.08.2024 10:16:10]daemon mgr: connecting => seafile_exiting (/run/build/seafile-client/src/daemon-mgr.cpp:213)
[09.08.2024 10:16:10][Daemon Mgr] stopping seafile daemon (/run/build/seafile-client/src/daemon-mgr.cpp:186)

The suspicious part is obviously this: SQL error: 1 - duplicate column name: commit_id

As far as I can telll, the daemon itself runs without issue, so files are still being synchronized. seaf-cli also seems to interact with my data without issue.

Any help to solve this would be deeply appreciated. Thanks!

[eKristensen]

EDIT: I see the issue is not the same, but it must be related as both get the SQL duplicate column error. The windows version seems to be able to keep running for some reason.

I was just about to create a bug report about the same issue on version 9.0.7 from here https://s3.eu-central-1.amazonaws.com/download.seadrive.org/seafile-9.0.7-en.msi

When I saw there was a new version I downloaded version 9.0.8 online (from here https://s3.eu-central-1.amazonaws.com/download.seadrive.org/seafile-9.0.8-en.msi )

Both versions have the issue described above.

There is no issue on a Windows 10 computer running version 9.0.7, but a Windows 11 compute running both 9.0.7 and 9.0.8 has the issue.

I tried to reinstall the program, and reset the seafile-data folder, but after a reboot the applet just doesn't show anything after seafile is restarted. It works perfectly after first login until seafile is restarted..

Files are still syncing.

It looks like this in the applet:

The Windows 11 version is Windows 11 Home 23H2 with all updates installed from Windows Update.

The interesting log is in applet.log:

[08/12/24 18:38:33]SQL error: 1 - duplicate column name: commit_id
:   ALTER TABLE FileCacheV2 ADD COLUMN commit_id TEXT

[feiniks]

Hi @eKristensen ， the SQL statement error should not cause a crash. Based on the logs in applet.log, the issue seems to stem from the inability to establish an RPC connection to the seaf-daemon. Could you please upload a more comprehensive seafile.log and applet.log for further analysis?

[eKristensen]

seafile.log

applet.log

I do see there are some odd "network errors" in the log: I did try to disable Windows Firewall and it changed nothing that I could observe. The Windows 10 computer I mention that works without issues is connected to the same network as the Windows 11 machine.

[eKristensen]

For the server I use a seafile container from docker.io:

REPOSITORY                       TAG          IMAGE ID      CREATED        SIZE
docker.io/library/mariadb        10.11        41d0c292085d  2 months ago   394 MB
docker.io/seafileltd/seafile-mc  10.0-latest  2f065562d4ff  14 months ago  1.49 GB
docker.io/library/memcached      1.6.18       6f2575dee31b  17 months ago  86.7 MB

[feiniks]

Hi @eKristensen, do you have any third-party security software installed? The logs suggest that a third-party process, potentially security software, might be terminating the GUI process.

[eKristensen]

I am 99% certain the device only has Windows Defender. I'll check, but it will take a while.

[eKristensen]

Confirmed, only Windows Defender.

[feiniks]

Hi @eKristensen , can you try temporarily stopping Windows defender and then running the client? Also in the log directory, is there any dump files generated?

[eKristensen]

Thanks for writing back. It looks like it fixed itself after the computer force rebooted itself, presumably after some updates. It works now. Thanks for your help :)

[troiganto]

@killing My apologies, but could this issue be reopened? The original report from before eKristensen dropped in hasn't been addressed. I use Seafile as a Flatpak on Fedora Silverblue 40, so I'm confident Windows Defender isn't messing with anything here :slightly_smiling_face:

[feiniks]

Hi @troiganto, the issue likely originated from the seaf-daemon repeatedly restarting and eventually reaching the maximum restart limit. Could you please send a more detailed seafile.log and applet.log?

[troiganto]

Hi, thanks for reopening the issue! I'm attaching seafile.log and applet.log from August 14 to 16 (today), after cutting away everything from earlier and removing some private information such as file names and server URL.

applet.log seafile.log

Looking through them myself, I found these lines:

[08/16/24 11:08:14] seaf-daemon.c(385): Failed to lock pidfile ~/Seafile/.seafile-data/seaf-daemon.pid: Resource temporarily unavailable

I think these are from when I was playing around with the flatpak and doing flatpak run com.seafile.Client. Not sure if they're relevant in any form.

Let me know if there's any other information I can provide. The logs go all the way back to 2023, but I didn't want to flood you with redundant information. :slightly_smiling_face:

[feiniks]

Hi @troiganto, from the seafile.log, seaf-daemon is already running, but the GUI tries to start another seaf-daemon. After you log out of the GUI, can you check if seaf-daemon is still running by ps -ef|grep seaf-daemon? Are you using the seafile GUI and the seafile CLI at the same time, which could be the cause of the problem?

[troiganto]

ah, how embarrassing. After running flatpak kill com.seafile.Client, everything seems to run smoothly again. :sweat_smile: I've observed things over a few days and several restarts and everything seems to be working again, so apologies for the extra work!