Arch Linux User Repository

@kuzalj, Port 8080 might be in use on your server. On my machine it assigned to seafdav, you can check it either with lsof or netstat:

sudo lsof -i:8080
COMMAND PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python3 600 seafile    8u  IPv4  32375      0t0  TCP localhost:http-alt (LISTEN)
python3 767 seafile    8u  IPv4  32375      0t0  TCP localhost:http-alt (LISTEN)
python3 769 seafile    8u  IPv4  32375      0t0  TCP localhost:http-alt (LISTEN)
python3 772 seafile    8u  IPv4  32375      0t0  TCP localhost:http-alt (LISTEN)
python3 774 seafile    8u  IPv4  32375      0t0  TCP localhost:http-alt (LISTEN)
python3 776 seafile    8u  IPv4  32375      0t0  TCP localhost:http-alt (LISTEN)


sudo netstat -tulpn | grep 8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      600/python3


=== seafdav.conf ===
[WEBDAV]
enabled = true
host = 127.0.0.1
port = 8080
fastcgi = false
share_name = /seafdav

P.S. You only need to install 'python-wsgidav-seafile' for WebDAV support (I need it so have to maintain this package :)

@trap000d

Thank you for the help. I had to install python-sqlalchemy, python-wsgidav-seafile, and I installed python-json5 for good measure.

Things seem to start fine with your command, but only if I switch the port from 8080. I don't think I have any seafile service running on 8080 in the configs so it should work fine?

Still getting the same generic error trying to start Seahub, seafile-server starts fine.

@kuzalj, According to my experience if any Python libraries are missed, seahub usually doesn't starting either without any messages in logs or some meaningless notifications. However if you try to start gunicorn manually, you might get some more from crash messages.

Assume your Seafile directory is "/home/seafile" and instance is "myhostname"

export SEAFILE_HOME=/home/seafile/myhostname
export CCNET_CONF_DIR=$SEAFILE_HOME/ccnet
export SEAFILE_CONF_DIR=$SEAFILE_HOME/conf
/usr/bin/python3 -m wsgidav.server.server_cli --server gunicorn --root / --log-file $SEAFILE_HOME/logs/seafdav.log --pid $SEAFILE_HOME/seafile-data/pids/seafdav.pid --port 8080 --host 0.0.0.0

UPD: Just remembered... It seems Seahub frontend requires now json5, so

sudo pacman -S python-json5

I am having an issue after updating to 7.1.5 from 7.1.4.

My steps were, shutdown seafile-server

upgrade packages

copy new /usr/share/seafile-server into /srv/seafile/instance/

run minor-upgrade.sh

restart seafile-server

start new seahub.service <--- fail

It seems my seafile-server services starts up fine. Running sh seahub.sh start gives nothing other than "Error:Seahub failed to start." I also can not find anything in logs giving anything more descriptive than this. Any tips?

Hello @all, Just a few notes in regarding to systemd units configuration.

The following option: After=seafile-server@.service means seahub will start IMMEDIATELY after seafile-server. Unfortunately with all >9000 options of systemd unit there is no single one with logic: "wait until the particular process has started indeed, e.g. has a PID file or active socket". So with standard unit files at each boot I'm getting the following in journal:

Sep 06 13:02:51 example.com seahub.sh[259]: Warning: seafile-controller not running. Have you run "./seafile.sh start" ?
Sep 06 13:02:51 example.com systemd[1]: seahub@example.service: Control process exited, code=exited, status=1/FAILURE
Sep 06 13:02:51 example.com systemd[1]: seahub@example.service: Failed with result 'exit-code'.
Sep 06 13:02:51 example.com systemd[1]: Failed to start Seafile hub.

And non-working seahub instance.

There are two kludgy ways to fix it, though.

A) Change the logic of seahub.sh, e.g. add loop (10 repeats every 5 seconds ?) to start_seahub():

function start_seahub () {
    before_start;
    echo "Starting seahub at port ${port} ..."
    check_init_admin;
    $PYTHON $gunicorn_exe seahub.wsgi:application -c "${gunicorn_conf}" --preload

    # Ensure seahub is started successfully
    for attempt in {1..10}
    do
        sleep 5
        if pgrep -f "seahub.wsgi:application" 2>/dev/null 1>&2; then
            echo
            echo "Seahub is started after $attempt attempts"
            echo
            return 0
        fi
    done
        printf "\033[33mError:Seahub failed to start.\033[m\n"
        echo "Please try to run \"./seahub.sh start\" again"
        exit 1;
    fi
}

B) Or implement the similar trick in seahub@.service

<pre><code>
[Unit]
Description=Seafile hub
After=network.target
Requires=seafile@.service

StartLimitIntervalSec=120
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=15s
Type=forking
WorkingDirectory=/home/seafile
Environment=SEAHUB_LOG_DIR=/home/seafile/logs
ExecStart=/home/seafile/seafile-server-latest/seahub.sh start
ExecStop=/home/seafile/seafile-server-latest/seahub.sh stop
User=seafile
Group=seafile

[Install]
WantedBy=multi-user.target
</code></pre>

Regards,

Hello @all,

I made some changes to the Systemd services units in the last update (v7.1.5-1).

Now Seahub has its own service (seahub@.service). You must now run seafile-server@ .service and then seahub @.service, e.g:

systemctl start seafile-server@instancename.tld.service
systemctl start seahub@instancename.tld.service

Why ? It is much cleaner, normally in forking type service, ExecStartPre must have an exit code, it was not the case before.
It's almost the same configuration as that proposed by the upstream.
https://download.seafile.com/published/seafile-manual/deploy/start_seafile_at_system_bootup.md

Regards, Joffrey

Hello @all, sorry for my late response.

I advise you not to use "seafile-helper" anymore, when I wrote this script the package did not have the same tree structure.

For the moment, for create or upgrade an instance you must just copy the /usr/share/seafile-server content to /srv/seafile/instance/ and execute installation or upgrade script.

I am not a fan of multiple symlinks level, all scripts must be copied in instance, so why make a symlink just for "seahub". You should compile Python bytecodes in the PKGBUILD if you do that.

Otherwise, I am not against the idea of implementing improvements, if that does not involve adding patches in the source code.

Re-multipule instances, note that the daemon management (seafile-controller) isn't really setup up to run multiple domains. It reads global processes information when starting and stopping sub-processes.

@mqs

I use seafile-helper and I believe it does copy over the /usr/share/seafile-server into your instance.

However, to be safe, I recursively copied seafile-server from /usr/share into my instance, and performed the minor upgrade using seafile-helper as normal. Seafile is working perfectly fine with that method.

I am not sure how to answer on multiple instances, but if you have multiple domains, you can run different Seafile instances on different domains which is kind of cool I guess.

@Joffrey what do you mean when you write the following?

upgrade seafile-server directory with /usr/share/seafile-server in your instances, as a release change

Do you mean that we should copy the contents of /usr/share/seafile-server into /srv/<instance>/seafile-server? Does seafile-helper simplify this and if yes with which invocation? Also: are there files which should not be overwritten or can we completely remove all the contents of seafile-server and copy the new stuff in?

On another note, I have wondered this since I installed the package some years ago, but why is seafile/seahub laid out for multiple instances (I don't know any other package which does this) and why don't they simply all link to the same static seahub files and have a separate directory for state and configuration in /var/lib and /etc? Is this due to issues with seafile?