[WSGI] Error:Seahub failed to start

I’m having a problem that I cannot fix without more info from the Seafile server

My Ubuntu server’s root user is running a CRON BASH script at night containing the following code. This is run under the seafile user account:

# Stop
sudo -u seafile /opt/seafile/seafile-server-latest/seahub.sh stop
sudo -u seafile /opt/seafile/seafile-server-latest/seafile.sh stop

# Clean
#sleep 5
#sudo -u seafile /opt/seafile/seafile-server-latest/seaf-gc.sh

# Start
sleep 5
sudo -u seafile /opt/seafile/seafile-server-latest/seafile.sh start
sudo -u seafile /opt/seafile/seafile-server-latest/seahub.sh start

This always worked correctly, until switching from the fastcgi to the new WSGI mode. Now when the CRON is run, seafile.sh starts correctly but the hub is failing:

Starting seafile server, please wait ...
Seafile server started


Starting seahub at port 8000 ...
Error:Seahub failed to start.
Please try to run "./seahub.sh start" again

And the strange thing is, then when running ‘sudo -u seafile /opt/seafile/seafile-server-latest/seahub.sh start’ under the root user account the hub is started correctly.

I have no idea what’s wrong, but I’m open for suggestions.

Did you also update seafile when switching to WSGI?
If so, check the permissions of the new seafile directory. I always forget to check that after an upgrade :confounded:

Yes I did. I can’t find out what the difference is between running the script as ROOT or as CRON ROOT. I would expect no difference.

Did you tried run
sudo -u seafile /opt/seafile/seafile-server-latest/seahub.sh start
sudo /opt/seafile/seafile-server-latest/seahub.sh start

generate this some error?

The seafile user can have bad permission for some files

Hi holantomas, thanks for your input.

I’m running the script from ROOT as there is a backup run before seafile is started again. This backup script requires root. Seafile is running under it’s own seafile user and cannot be started straight from root as you suggest, therefore I’m using the sudo -u seafile to start it under the right user.

I’ve just chowned -R the entire seafile folder, but no difference.
What made a difference is that when I fall back to fastcgi, seahub can be started from root again! I was expecting an error.

I suggest run it under root for test, not as a solution. So check if some another seafile instance or program not using same port