6.2.5 seahub 500 ISE and ImportError

dennis · June 9, 2018, 5:49pm

Hey there,

I’m trying to run seafile 6.2.5 on linux with nginx. Seafile itself is fine, the problem comes when I try to access a file (or a preview) via the Webinterface: I’m getting “500 Internal Server Error” according to nginx’ log. I checked “seahub_django_request.log”, it states “SearpcError: Error received: 511 Unknown service (In _start_service)”. There’s a thread in this forum that says this is because “seaf-server” is down. Checking for this revealed it is up, but I think it is because the controller process restarted it like it is supposed to. logs/controller.log:
[06/02/18 18:33:50] seafile-controller.c(186): starting seaf-server …
[06/02/18 18:33:50] seafile-controller.c(73): spawn_process: seaf-server -F /opt/seafile/conf -c /opt/seafile/ccnet -d /opt/seafile/seafile-data -l /opt/seafile/logs/seafile.log -P /opt/seafile/pids/seaf-server.pid
[06/02/18 18:33:50] seafile-controller.c(88): spawned seaf-server, pid 3244
[06/02/18 18:34:10] seafile-controller.c(416): seaf-server need restart…
[06/02/18 18:34:10] seafile-controller.c(186): starting seaf-server …
[06/02/18 18:34:10] seafile-controller.c(73): spawn_process: seaf-server -F /opt/seafile/conf -c /opt/seafile/ccnet -d /opt/seafile/seafile-data -l /opt/seafile/logs/seafile.log -P /opt/seafile/pids/seaf-server.pid
[06/02/18 18:34:10] seafile-controller.c(88): spawned seaf-server, pid 3260
[06/02/18 18:34:20] seafile-controller.c(416): seaf-server need restart…
[06/02/18 18:34:20] seafile-controller.c(186): starting seaf-server …
[06/02/18 18:34:20] seafile-controller.c(73): spawn_process: seaf-server -F /opt/seafile/conf -c /opt/seafile/ccnet -d /opt/seafile/seafile-data -l /opt/seafile/logs/seafile.log -P /opt/seafile/pids/seaf-server.pid
[06/02/18 18:34:20] seafile-controller.c(88): spawned seaf-server, pid 3274
[06/02/18 18:34:30] seafile-controller.c(416): seaf-server need restart…
[06/02/18 18:34:30] seafile-controller.c(186): starting seaf-server …
…and so on.

So I think seaf-server just crashes when accessing the file.
That’s the situation with fastcgi, so I thought I’d like to use uwsgi anyway, so try this.
There is an example config for uwsgi here, but running it results in an error:
Traceback (most recent call last):
File “/opt/seafile/seafile-server-latest/seahub/seahub/init.py”, line 2, in
from signals import repo_created, repo_deleted
File “/opt/seafile/seafile-server-latest/seahub/seahub/signals.py”, line 2, in
import django.dispatch

I suppose those two errors have the same cause, as it only affects seahub (upload and download via client is ok).
Here’s the nginx config for seahub, it’s tested only with fastcgi:
location /seafhttp {
rewrite ^/seafhttp(.*)$ $1 break;
proxy_pass http://127.0.0.1:8082;
client_max_body_size 0;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
send_timeout 36000s;
}

Any help would be appreciated, I’m outta ideas.

wthess · June 9, 2018, 8:14pm

Any particular reason that you are using that config for wsgi rather than the method described in the Seafile manual?

dennis · June 9, 2018, 9:29pm

Thanks for taking the time to reply, wthess!
As I can’t spot a difference between the nginx config block for /seafhttp to this, I’ve checked the manual again. Changelog for 6.2’s location block is applied now, but behaves close to with fastcgi. (I double checked it is started without fastcgi). seahub_django_request.log doesn’t log the 511-error anymore.

If you’re referring to the uwsgi-config, I wasn’t able to find any special uwsgi config in the manual. Please let me know if I’m just bad at searching in case there is info for that.
Actually, from what I understand you won’t need uwsgi to run seahub, but since the fastcgi error it was my first shot

wthess · June 10, 2018, 3:01am

WSGI is built into Seafile. No need to run a separate implementation of it. Also, keep in mind, that 6.2.5 is the very last version where fastcgi will be supported. 6.3 will not support it.

And, one thing that a lot of people miss after switching from fastcgi to wsgi is the startup script, whether it’s systemd or init.d. You have to start the seafile scripts without fastcgi from there as well.

Also, you only included a small portion of your nginx config. You only included the seafhttp section, which handles file transfers. That shouldn’t be related to your problem.

Can you post your other config files here, ccnet.conf, seafile.conf, and seahub_settings.py. Also, posting the remainder of your nginx config may help as well.

Also, which flavor OS are you running Seafile on? What version of the OS?

dennis · June 10, 2018, 5:29am

Ok, here we go. conf/ccnet.conf:

[General]
USER_NAME = cloud
ID = 57ded0cae5162fba68c7aef1d51e3d09d4348636
NAME = cloud
SERVICE_URL = https://myurl

[Client]
PORT = 13419

[Network]
PORT = 10001

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = seafile
PASSWD = mypass
DB = ccnet-db
CONNECTION_CHARSET = utf8

conf/seafdav.conf:

[WEBDAV]
enabled = false
port = 8080
fastcgi = false
share_name = /seafdav

conf/seafile.conf:

[fileserver]
host = 127.0.0.1
port = 8082

[network]
port = 12001

[database]
type = mysql
host = 127.0.0.1
port = 3306
user = seafile
password = mypass
db_name = seafile-db
connection_charset = utf8

conf/seahub_settings.py:

# -*- coding: utf-8 -*-
SECRET_KEY = "some secret key"

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'seahub-db',
        'USER': 'seafile',
        'PASSWORD': 'mypass'
        'HOST': '127.0.0.1',
        'PORT': '3306'
    }
}

FILE_SERVER_ROOT = 'https://myurl/seafhttp'

nginx-config:
server {
server_name myurl;
listen 80;

        return 301 https://$server_name$request_uri; # enforce https

        server_tokens off;
}

server {
        server_name myurl;
        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/ssl/cloud.crt;
        ssl_certificate_key /etc/nginx/ssl/cloud.key;
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
        ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4;
        ssl_prefer_server_ciphers on;
        ssl_ecdh_curve secp384r1;

        proxy_set_header X-Forwarded-For $remote_addr;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
        server_tokens off;

        location ~ /\. { access_log off; log_not_found off; deny all; }
        location ~ ~$ { access_log off; log_not_found off; deny all; }

        location / {
                proxy_pass         http://127.0.0.1:8000;
                proxy_set_header   Host $host;
                proxy_set_header   X-Real-IP $remote_addr;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Host $server_name;
                proxy_read_timeout  1200s;

                # used for view/edit office file via Office Online Server
                client_max_body_size 0;

                access_log      /var/log/nginx/seahub.access.log;
                error_log       /var/log/nginx/seahub.error.log;
        }

        location /seafhttp {
                rewrite ^/seafhttp(.*)$ $1 break;
                proxy_pass http://127.0.0.1:8082;
                client_max_body_size 0;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_connect_timeout 36000s;
                proxy_read_timeout 36000s;
                proxy_send_timeout 36000s;
                send_timeout 36000s;
        }

        location /media {
                root /opt/seafile/seafile-server-latest/seahub;
        }

        location /seafdav {
                # https://forum.seafile.com/t/tutorial-seafdav-with-wsgi-behind-nginx/4341
                proxy_pass         http://127.0.0.1:8080;
                proxy_set_header   Host $host;
                proxy_set_header   X-Real-IP $remote_addr;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Host $server_name;

                client_max_body_size 0;

                proxy_connect_timeout  36000s;
                proxy_read_timeout  36000s;
                proxy_send_timeout  36000s;
                send_timeout  36000s;

                proxy_request_buffering off;

                access_log      /var/log/nginx/seafdav.access.log;
                error_log       /var/log/nginx/seafdav.error.log;
        }
}

I hope this helps.

seafile   5445  0.4  2.9  37044 28036 ?        S    06:58   0:04 python2.7 /opt/seafile/seafile-server-6.2.5/seahub/thirdpart/gunicorn seahub.wsgi:application -c /opt/seafile/seafile-server-6.2.5/runtime/seahub.conf -b 0.0.0.0:8000 --preload

I’m running Slackware, the problem occurs on x64 as well as on arm (raspi).

Well, the problem was (and still is) that downloading from WebUI isn’t working, so I think the seafhttp block is related.
Here’s what the logs say from the moment I click on the download-button in the WebGUI to download “fbox.txt”:

==> logs/ccnet.log <==
[06/10/18 07:24:33] ../common/session.c(398): Accepted a local client
[06/10/18 07:24:33] ../common/peer.c(941): libevent got an error! what=33, errno=104 (Connection reset by peer)
[06/10/18 07:24:33] ../common/peer.c(943): Local peer down
[06/10/18 07:24:33] ../common/peer.c(943): Local peer down
[06/10/18 07:24:33] ../common/peer.c(943): Local peer down

==> logs/seahub_django_request.log <==
2018-06-10 05:24:33,703 [ERROR] django.request:256 handle_uncaught_exception Internal Server Error: /lib/268ec352-f199-4505-84ba-fdf866fd6bdf/file/fbox.txt
Traceback (most recent call last):
  File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/core/handlers/base.py", line 132, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/auth/decorators.py", line 27, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/base/decorators.py", line 74, in _decorated
    return func(request, *args, **kwargs)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/views/file.py", line 385, in view_lib_file
    return _file_view(request, repo_id, path)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/views/file.py", line 542, in _file_view
    handle_textual_file(request, filetype, inner_path, ret_dict)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/views/file.py", line 226, in handle_textual_file
    raw_path, file_enc)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/views/file.py", line 140, in get_file_content
    file_type=file_type) else ('', '', '')
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/views/file.py", line 153, in repo_file_get
    file_response = urllib2.urlopen(raw_path)
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 429, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 447, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1228, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1201, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1121, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 438, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 402, in _read_status
    raise BadStatusLine(line)
BadStatusLine: ''

==> logs/controller.log <==
[06/10/18 07:24:41] seafile-controller.c(416): seaf-server need restart...
[06/10/18 07:24:41] seafile-controller.c(186): starting seaf-server ...
[06/10/18 07:24:41] seafile-controller.c(73): spawn_process: seaf-server -F /opt/seafile/conf -c /opt/seafile/ccnet -d /mnt/smb_data/seafile-data -l /opt/seafile/logs/seafile.log -P /opt/seafile/pids/seaf-server.pid
[06/10/18 07:24:41] seafile-controller.c(88): spawned seaf-server, pid 5765

==> logs/ccnet.log <==
[06/10/18 07:24:41] ../common/session.c(398): Accepted a local client
[06/10/18 07:24:41] ../common/session.c(398): Accepted a local client

==> logs/seafile.log <==
[06/10/18 07:24:41] http-server.c(161): fileserver: worker_threads = 10
[06/10/18 07:24:41] http-server.c(176): fileserver: fixed_block_size = 8388608
[06/10/18 07:24:41] http-server.c(191): fileserver: web_token_expire_time = 3600
[06/10/18 07:24:41] http-server.c(206): fileserver: max_indexing_threads = 1
[06/10/2018 07:24:41 AM] ../common/mq-mgr.c(54): [mq client] mq cilent is started
[06/10/2018 07:24:41 AM] listen-mgr.c(120): listen on port 12001 for block tranfer
[06/10/2018 07:24:42 AM] size-sched.c(96): Repo size compute queue size is 0

I can happily download/upload this file or other files via the Client.

wthess · June 10, 2018, 8:36pm

Ok… So I misunderstood you. I thought you were saying that the problem you were having is clicking on previews but that you could upload and download. However, it seems you can’t upload or download from the ui, whether you click the item or not. Is that correct?

One thing I noticed in the seafile log is it states it is listening for block transfers on port 12001, which is no longer used as far as I know. Also, seafhttp on port 8082 handles transfers and it works with the client. The client doesn’t use django, as far as I know, and django is the one reporting the error. You could try commenting out the [network] section of your seafile.conf file, the one containing the port=12001.

However, your logs are indicating that your connection is being reset by the peer and django says it’s because it can’t read the status, and python is reporting the reasoning for it which is null. That’s why it’s an “unhandled exception”. Then, it appears that your seafile server restarts itself and starts listening for block transfers on port 12001.

Your Nginx config looks fine to me, unless I missed something. I will do some digging to see if I can narrow this down some.

wthess · June 10, 2018, 8:50pm

Also, could you check the file server url in the admin settings and make certain it is set properly, and with no trailing spaces at the end?

dennis · June 10, 2018, 9:14pm

Yes, this is correct.
However, I can upload and download stuff via the client.

I’ve checked the admin settings:
SERVICE_URL: https://myurl
FILE_SERVER_ROOT: https://myurl/seafhttp
No trailing spaces or slashes

I noticed that the network port 12001 isn’t set by default anymore, also it’s mentioned in the changelog. Disabling this leads to a 500 error on login page of the webui and the client can’t sync anymore. I ran into this when setting things up, I remember.

I’ll try to check if I can configure the client to not use 12001. Can take a day or two, I’ll report back on that.

wthess · June 11, 2018, 3:21am

Interesting… I use 6.2.5 and I don’t use 12001. I haven’t used it since version 4. That setting isn’t even in my setup files as it is deprecated. I also use https. According to your NGinx config, there are only two listen ports… port 80, which is redirected to https and port 443 for your https. The two ports that are passed are to port 8000 for seahub and port 8082 for seafhttp. 12001 isn’t even in any of those, so I’m not certain why it is failing on port 12001 unless that’s needed by mysql. I don’t use mysql, so I would have to dig for some information on how it operates, but I believe it uses 3306 or something like that.

As a test, let’s bypass NGinx… Access seafile internally using port 8000 from a browser, without using the domain name/public IP… For example, http://192.168.1.XXX:8000. Then try the upload or download.

Todd

wthess · June 11, 2018, 3:33am

Additionally, looking further into the manual, it seems to contradict itself. In the changelog for version 4.3.0, ports 10001 and 12001 no longer listen by default. Yet, in the development section, it states that the seafile install script will ask for those two ports. However, the seafile install script as detailed in the “Deploying Seafile with SQLite” does not include ports 10001 and 12001, but the section for MySQL does make mention of it, but only in a screenshot. I’m thinking that the manual needs to be updated, as it is ambiguous.

With NGinx, though, ports 10001 and ports 12001 are not being passed. Externally, ports 443 and 80 are your listen ports, and the only proxy passes you have are to port 8000 and 8082 in your location settings, which is correct, btw. So, 12001 and 10001 are not in use, but it appears that for some reason, your Seafile is listening on 12001 and using it somehow.

That could be a portion of the issue, and the reasoning for the clients working, but not the UI. It appears that they may be set up differently.

dennis · June 13, 2018, 8:00pm

Thanks for your replies, Todd.
Bypassing nginx gives the same results as with nginx. The mysql-stuff is only on tcp 3306, you’re correct.
The install script setup-seafile-mysql.py mentions 10001 and 12001 in its code, but from the notes I took when setting things up, it looks the script didn’t ask for anyting those ports were the default settings. I’m pretty sure I added them to the server’s config myself since the client’s config referenced them (please see below) and it worked when listening on those ports.
But yeah, the manual should be updated, too.

Ok, I removed the [Client] and [Network] sections from ccnet.conf and seafile.conf. Additionally, I’ve enabled seafdav so I can test that. I’ve checked netstat, nothing’s listening on 12001 or 13419 anymore. That should comply with the changelog’s note I hope. These ports are the only ones I see, it matches with the seafile config.

tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      18936/python2.7
tcp        0      0 127.0.0.1:8082          0.0.0.0:*               LISTEN      18937/seaf-server
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      18978/python2.7
tcp        0      0 127.0.0.1:44668         127.0.0.1:3306          ESTABLISHED 18937/seaf-server
tcp        0      0 127.0.0.1:3306          127.0.0.1:44666         ESTABLISHED 7020/mysqld
tcp        0      0 127.0.0.1:44666         127.0.0.1:3306          ESTABLISHED 18934/ccnet-server
tcp        0      0 127.0.0.1:3306          127.0.0.1:44666         ESTABLISHED 7020/mysqld

3306 is mysql. Nothing on IPv6 and no UDP either. Nginx is listening on 80 and 443.

Testing:

Access via Website: Downloading a file (alsamixer.PNG) results in 502 error on the client.

Nginx log this in its error log:

2018/06/13 20:24:22 [error] 16279#0: *444 upstream prematurely closed connection while reading response header from upstream, client: x.x.x.x, server: myurl, request: "GET /seafhttp/files/d48cba06-250d-43b2-b19c-3b6487a475a1/alsamixer.PNG HTTP/1.1", upstream: "http://127.0.0.1:8082/files/d48cba06-250d-43b2-b19c-3b6487a475a1/alsamixer.PNG", host: "myurl", referrer: "https://myurl/"

ccnet.log:

[06/13/18 20:24:21] ../common/peer.c(941): libevent got an error! what=33, errno=104 (Connection reset by peer)

controller.log shows no errors.
seahub_django_request.log:

2018-06-13 18:24:18,541 [ERROR] django.request:256 handle_uncaught_exception Internal Server Error: /thumbnail/268ec352-f199-4505-84ba-fdf866fd6bdf/1024/IMG_0059.jpg
Traceback (most recent call last):
  File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/core/handlers/base.py", line 132, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/auth/decorators.py", line 27, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/views/decorators/http.py", line 158, in inner
    response = func(request, *args, **kwargs)
  File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/thumbnail/views.py", line 90, in thumbnail_get
    repo = get_repo(repo_id)
  File "/opt/seafile/seafile-server-6.2.5/seafile/lib/python2.7/site-packages/seaserv/service.py", line 342, in get_repo
    return seafserv_threaded_rpc.get_repo(repo_id)
  File "/usr/lib/python2.7/site-packages/pysearpc/client.py", line 110, in newfunc
    ret_str = self.call_remote_func_sync(fcall_str)
  File "/opt/seafile/seafile-server-6.2.5/seafile/lib/python2.7/site-packages/ccnet/rpc.py", line 75, in call_remote_func_sync
    req_id = self._start_service(client)
  File "/opt/seafile/seafile-server-6.2.5/seafile/lib/python2.7/site-packages/ccnet/rpc.py", line 36, in _start_service
    raise SearpcError("Error received: %s %s (In _start_service)" % (rsp.code, rsp.code_msg))
SearpcError: Error received: 511 Unknown service (In _start_service)

seahub.log:

2018-06-13 18:24:16,111 [ERROR] seahub.thumbnail.utils:136 generate_thumbnail ''

I’m not sure if the thumbnails are generated when accessing the file, I clicked the download button in the GUI (?dl=1). As django’s error is repeated for every image file (including alsamixer.PNG) in my library, I suppose the thumbnails are generated for the whole folder at once.

Access via latest windows client (6.1.8), installed for the first time on a test box so we won’t bother with update-related problems on this side. The only place I found some logfiles is %userprofile%\ccnet\logs, if there should be additional logs please let me know. Monitoring the network shows it’s just connectiong to myurl:443, so no deprecated ports are used.

applet.log:

[06/13/18 20:54:13]starting seaf-daemon:  ("-c", "C:/Users/Dennis/ccnet", "-d", "C:/Users/Dennis/Seafile/seafile-data", "-w", "C:/Users/Dennis/Seafile")
[06/13/18 20:54:14][Rpc Client] connected to daemon
[06/13/18 20:54:14][RPC] failed to start rpc server: 511 Unknown service.
[06/13/18 20:54:15][Rpc Client] connected to daemon
[06/13/18 20:54:15][Rpc Client] connected to daemon
[06/13/18 20:54:15][MessageListener] connected to daemon
[06/13/18 20:54:16]Starting the network status detector
[06/13/18 20:54:16][AutoUpdateManager] cancel all download tasks
[06/13/18 20:54:16][AutoUpdateManager] clean file caches db  
[06/13/18 20:54:16][AutoUpdateManager] clean file caches
[06/13/18 20:54:17][Rpc Client] connected to daemon
[06/13/18 20:54:17][Rpc Client] connected to daemon
[06/13/18 20:56:37][Daemon Mgr] stopping ccnet/seafile daemon

seafile.log shows some starting messages and then this many times:

[06/13/18 20:55:45] http-tx-mgr.c(1415): Bad response code for GET https://myurl/seafhttp/repo/268ec352-f199-4505-84ba-fdf866fd6bdf/commit/HEAD: 404.
[06/13/18 20:55:45] clone-mgr.c(864): Transition clone state for 268ec352 from [check server] to [error]: check server.
[06/13/18 20:55:50] clone-mgr.c(847): Transition clone state for 268ec352 from [error] to [check server].

ccnet.log (i omitted repeating messages):

[06/13/18 20:54:12] ccnet-daemon.c(193): starting ccnet client 6.1.8
[06/13/18 20:54:12] ccnet-daemon.c(195): ccnet source code version 5b9f64c2438517e1c95b28678097419542d1d084
[06/13/18 20:54:12] ../common/session.c(132): using config file C:/Users/Dennis/ccnet\ccnet.conf
[06/13/18 20:54:12] ../common/session.c(418): Listen on 127.0.0.1 13419
[06/13/18 20:54:12] ../common/session.c(290): Update pubinfo file
[06/13/18 20:54:13] ../common/session.c(398): Accepted a local client
[06/13/18 20:54:14] ../common/peer.c(943): Local peer down
[06/13/18 20:54:14] ../common/session.c(398): Accepted a local client
[06/13/18 20:54:15] ../common/peer.c(943): Local peer down
[06/13/18 20:54:17] ../common/session.c(398): Accepted a local client
[06/13/18 20:56:37] ../common/peer.c(943): Local peer down
[06/13/18 20:56:37] ../common/peer.c(941): libevent got an error! what=33, errno=0 (No error)
[06/13/18 20:56:37] ../common/peer.c(943): Local peer down
(last 2 messages repeat two more times)

The 13419 listening port was interesting, so this is ccnet.conf on the client:

[General]
USER_NAME = Dennis
ID = 80d37b9e66d1d7b75edcbb5d21c9bafdcab17375
NAME = Dennis@

[Network]
PORT = 10001

[Client]
PORT = 13419

13419 is listening on 127.0.0.1, but there are no connections to myurl:10001 and nothings listening on 10001 on the client. I think this is because the changes to 6.2.x obviously aren’t implemented in 6.1.8 :). Seems this isn’t related to the problem.

WebDAV. Suprisingly, I can upload and download files via WebDAV!?! Network monitoring revealed it’s connecting to myurl:443, so everything is handled via nginx’ /seafdav location correctly. This is quite unxepected.

First thought: the webdav component doesn’t use searpc and that’s why we don’t get the 502/511 errors. If so I’ll try to investigate on searpc, maybe I’m lacking some runtime dependencies.

Any ideas are highly appreciated

bionade24 · June 14, 2018, 1:22pm

Why do you want to use Slackware? There were some guys in the forum who wanted to use SeafDAV and run it on Arch Linux, but they didn’t get it working with WSGI. I also use Arch on my Desktop, but like Slackware it’s bad for Server. I don’t know much about Slackware, but I think there are some dependency missings, you can hardly solve. So I would switch or use some container Software to run SeaFile.

Edit: Ok, the idea of Slackware is pretty cool, but I think you have some dependency problems. Can you use pip on Slackware?
Another option: What about trying SeaFile to run in a Debian LXC container?

dennis · June 14, 2018, 6:20pm

Seafdav is working, the client and the website don’t. No idea for arch, sorry.
Thanks for your input, pip list says:

Package          Version
---------------- -----------
appdirs          1.4.3
beautifulsoup4   4.6.0
caca             0.99b19
certifi          2018.1.18
chardet          3.0.4
cupshelpers      1.0
Cython           0.28.2
docutils         0.14
getmail          5.6
gpg              1.11.1
html5lib         0.999999999
idna             2.6
libwebp          0.0
lxml             4.2.1
M2Crypto         0.27.0
Mako             1.0.7
mercurial        4.5.3
mysqlclient      1.3.12
netsnmp-python   1.0a1
notify2          0.3.1
packaging        16.8
Pillow           5.1.0
pip              10.0.1
py-bcrypt        0.4
pycairo          1.16.3
pycups           1.9.73
pycurl           7.43.0.1
pygobject        3.28.2
pyparsing        2.2.0
python-ldap      3.0.0
python-libpisock 0.12.5
python-memcached 1.59
python-sane      2.8.3
requests         2.18.4
rpm              4.14.1
scons            3.0.1
setuptools       39.0.1
six              1.11.0
typing           3.6.4
urllib3          1.22
urwid            1.0.3
webencodings     0.5.1
zenmap           7.70

This is the complete output, I don’t think seafile uses beautifulsoup and some more.

bionade24 · June 14, 2018, 6:39pm

Do you have python-requests installed? And Arch is not my problem, my server runs debian
And you have problems with ccnet, not seafrpc

wthess · June 17, 2018, 9:21pm

I’m assuming this is on your Windows machine. The RPC service handles remote procedure calls which is necessary to transfer files. The RPC service should be in the “Running” state on your Windows machine.

There are two important ones:
Remote Procedure Call (RPC)
RPC Endpoint Manager

[EDIT]
BTW, Although the error indicated is a Seafile related error, I’m not certain whether or not the client utilizes the RPC service for Windows, but it’s something worth looking at.

This error means that it couldn’t find that particular page. This could be due to a permissions problem, the location doesn’t exist, or something else triggering it to fail. In this case, it’s probably related to the RPC service not starting.

The RPC service not starting seems to be the first thing in a chain of events. According to the error, it doesn’t exist. That service can be found at /opt/seafile/seafile-server-6.2.5/seafile/lib/python2.7/site-packages/ccnet/rpc.py on your machine.

Check permissions on that folder and its file. Check to see if it even exists.

dennis · June 18, 2018, 5:33pm

Right.
I took a look, both services are started. I think you’re right and the client doesn’t utilize those windows services, but checking this doesn’t harm. (There’s a libsearpc-1.dll in the seafile-client installation dir, so I think it uses the same rpcs as the server does.)

I think the 404 is related to the RPC problem, but I have no idea what file is requested. I have a folder “seafile-data/storage/commits/268ec352-f199-4505-84ba-fdf866fd6bdf” though, so the repo exists at least. No idea if this info is helpful

-rw-r--r-- 1 seafile seafile 12525 May 10 14:59 /opt/seafile/seafile-server-6.2.5/seafile/lib/python2.7/site-packages/ccnet/rpc.py

Looks fine.

# find /opt/seafile/ ! -user seafile ! -group seafile

No output: so everything’s owner and group is seafile.

# find /opt/seafile/ -type d ! -perm 755
/opt/seafile/
/opt/seafile/conf
/opt/seafile/ccnet

Directories are accessible for nginx also in order to serve static content. /opt/seafile itself isn’t readable by other, but executable so nginx can enter the directory tree. /opt/ is 755 again, u&g = root.

One thing I noticed: all the .py files in /opt/seafile/seafile-server-6.2.5/seafile/lib/python2.7/site-packages/ccnet, seafile and seaserv aren’t executable. I think they’re imported by other py-modules and don’t need to be +x. But maybe they should? Can you check with your installation, please?

//edit1: added “no output” so it’s clear the find command finds nothing.

wthess · June 18, 2018, 6:08pm

It’s a python script, so it doesn’t need to be executable. I checked my server and it’s set to 644 on permissions. But, I did notice that yours is in lib. Mine is in lib64 since I’m using the 64 bit version. I’m also on Debian, so my folder structure is different than yours.

I looked at the script and this is the function that is failing. I’m not versed in python scripting, but I’ll try to follow the code to see what it’s trying to do. Looking at your logs, this seems to be the first event that fails, although your times in your logs vary by about 2 hours.

def _start_service(self, client):
    req_id = client.get_request_id()
    req_str = self.service_name
    if self.is_remote:
        req_str = "remote " + self.remote_peer_id + " " + self.service_name
    client.send_request(req_id, req_str)
    rsp = client.read_response()
    if rsp.code != "200":
        raise SearpcError("Error received: %s %s (In _start_service)" % (rsp.code, rsp.code_msg))
    return req_id

dennis · June 18, 2018, 6:48pm

Yeah, good, I think readwrite for seafile-user should suffice, too. Thanks for checking.
The 2 hours difference in the log is because seafile/hub/ccnet log in local time and django logs UTC. I’m on UTC+2 due to daylight saving

wthess · June 18, 2018, 6:54pm

What action is it that you are taking that generates that django error? Is it when you try to upload? If so, are you uploading from the client or the webui when that error is generated. I’m assuming the webui since django is involved. Also, are you trying this from the server or a remote machine?

dennis · June 18, 2018, 7:12pm

The django error I’ve posted is from downloading a file via WebUI from a remote machine.

To be clear, I’m not using debian, I’m trying to set this up on Slackwarearm (32-bit) on a raspberry pi2 and 3, hence the lib path. @bionade24 runs it on debian he/she said.