Seahub fails silently after migration from Debian 8 to Debian 11

I’ve been running Seafile 7.0.5 for a long while on a very old Debian 8 server. Now I’m finally migrating it to a more modern VPS, but I’m running into all kinds of issues. I correctly transferred all the files using rsync to preserve permissions, and checked everything using md5sum and seaf-fsck. Sadly, I noticed I couldn’t get Seahub to start. Looking further into it, I remembered that 7.0.5 is python2.7 based. Even though I was in the end able to fulfil dependencies by sideloading pip2, seahub refused to play to work.

I decided to try 7.1.5 since that made a lot more sense, as it uses python3. I ran the upgrade script and made sure all the dependencies were install. Seafile started fine, but Seahub would do this strange thing where it would start, but not actually run. So there was no error, but the gunicorn process just dies when the bash script finishes.

I was guessing this was because it was made for python 3.6 and not python 3.9, so I ended up upgrading to Seafile 9.0.6, the very latest version. I ran the 8 and 9 upgrade scripts, yet I still was unable to get things to work correctly. I did find I had to install libffi-dev and then pip install a specific version of cffi, but once I did that I had the same behaviour as before.

As you can see:
seafile@sys:~$ pwd
seafile@sys:~$ ./ start

Starting seahub at port 8000 …

Seahub is started


seafile@sys:~$ ps aux | grep seahub
seafile 50816 0.0 0.0 6256 712 pts/0 S+ 02:35 0:00 grep seahub
seafile@sys:~$ ./ start-fastcgi

Starting seahub (fastcgi) at …

Warning: File comment has changed since version 6.3, while table base_filecomment is not migrated yet, please consider migrate it according to v6.3.0 release note, otherwise the file comment feature will not work correctly.

Unknown command: ‘runfcgi’
Type ‘ help’ for usage.
Error:Seahub failed to start.

Logs don’t have a word written to it by Seahub, weirdly.

Could someone help me? I can easily retransfer the old 7.0.5 install and start from scratch. I was just not expecting this to be such a bother. I hope someone knows what to do or what to look for.

You can try to set the daemon variable to False in to print the python stack trace when crashing.
Then launch Seahub normally (i.e without start-fastcgi which isn’t supported for a while).

Thanks a ton! That was exactly what I had been looking for all night last night but couldn’t figure out how to get to. It turned out to be an incorrect bind statement that remained from pre-migration. Such a silly thing. I’m quite surprised that Seahub doesn’t log this anywhere, and neither does it display this error normally. Quite annoying! Thanks again for your great help :slight_smile: