Notification Server used by clients?

Hi,

i just upgraded the server to 10.0.1, the client to 9.0.2 and enabled the notification server. I checked that its running in the logs and /notification/ping is reachabel from the outside. In short. It should work just fine.

Nevertheless i could not recognize any improvements when syncing libraries, i.e. the delay of sync after a change on another device. Hence, i checked the API calls on the Seahub WebUI and learned, that the /notification endpoint is never called and there is also no websocket connection established, neither there is an error.

I could not check on the outgoing connections of the Desktop Sync Client yet, but are the clients already using the websocket notifications yet? I mean the sync time is okaish (always was), but it’s far from instant (>>10s / Average around 30s).

Great work anyway on v10. Upgrade worked flawlessly! :slight_smile:

Edit: tbh. i’m not sure if the instant synchonization is actually supposed to work in the WebUI

The web ui is not using notification server for now. It may be added in the future.

9.0.2 should use notification server. You can check whether you have the following message in the log:

Notification server is enabled on the remote server

Detection of updates on the server and lock information update should be almost instant.

1 Like

I checked both applet.log, events.log and seafile.log but this message does not appear. I doubled checked the webserver proxy routing and the logs to double check that the notification server is running properly. I even tested the client with various servers with notificaiton server enabled.

Edit:
Client 9.0.2 on Windows
Client 9.0.2 on Linux
Server 10.0.1 (docker installation)

I can confirm that I do not see this log message either.

Client 9.0.2 on Windows
Client 9.0.1 on Linux
Server 10.0.1 (native installation)

(Side note: There is no 9.0.2 version for Linux on Fedora yet. dnf still ships v8.x and Flatpak didn’t get the update either)

Hello @freezziey, which os are you using? Currently, the linux client does not support the notification server.

I checked again on Windows. Now the log appears :slight_smile: On the first Windows test i did not check the log and only tested on linux. That explains that.

So everything works as expected i guess. Nevertheless, the synchronization time is still far from instant. Not sure what is the cause here.

I have the same here.

Installed the notification server on 10.0.1
Seems to have been successfully done:

cat seafile/logs/notification-server.log 
2023/07/06 14:50:12 notification server started.

Windows client 9.0.3 and Mac Client 9.0.3

When I add a test.txt file to a shared library on Mac, the sync took 30 seconds to appear on the PC.
Deleting the same text file on the PC took about 10 seconds to appear on the Mac.

@daniel.pan is that the expected behaviour? From your explanation above I am not sure what actually should improve with this notification server.

The documentation for configuring notification server has been updated. Some instructions are added to the end of the document for how to check whether notification server really works. You can follow the instructions.

1 Like

@Jonathan
In the documentation it says to check
https://{server}/notification/ping
Should it not be
https://{server}/notification-server/ping?

If not, then the fix suggested here does not make sense or the answer given here is wrong.

The document is correct. The url prefix for notification server remains “notification”. The code for seahub was changed to another url prefix.

1 Like

Thank you @Jonathan !

I updated my nginx .conf file based on the manual and get the “pong” when I run the https://{server}/notification/ping

I added and deleted text files for testing purposes and the sync between the clients took about 3-5 seconds.

Big improvement!

I hope it works for everybody :wink:

Hello Jonathan,

could you please update the decomentation if an apache server is used as reverse proxy.

The statements for the notification server must be set before the seahub server statement to get it working:

#
# Notification Server
#
ProxyPass /notification/ping  http://127.0.0.1:8083/ping/
ProxyPassReverse /notification/ping  http://127.0.0.1:8083/ping/

ProxyPass /notification  ws://127.0.0.1:8083/
ProxyPassReverse /notification ws://127.0.0.1:8083/

#
# Seafile fileserver
#
ProxyPass /seafhttp http://127.0.0.1:8082 timeout=18000
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp - [QSA,L]

#
# Seahub
#
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/

Ubuntu 20.04
Apache/2.4.57 (Ubuntu)

1 Like

Thank you for the suggestion, the documentation has been updated.

After I enable the notification server, I can’t access

https://{server}/notification/list

for the web notification. Is there a way to fix this?

hi
how did you enable server notification? did you add the block to nginx or apache?
we need more details to help you

https://github.com/haiwen/seahub/issues/5513 will be ifxed in the next release

Update from the logs. It shows the seconds it taks to synchronize. May there is a reason other than the notification server. maybe my server ist just slow? But 30s is quite a long time

-----Client Startup-----
[07/30/23 17:14:45] starting seafile client 9.0.2
[07/30/23 17:14:45] rpc server started.
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] File syncing protocol version on server https://cloud.domain.de is 2. Client file syncing protocol version is 2. Use version 2.
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:46] start to serve on pipe client
[07/30/23 17:14:47] Notification server is enabled on the remote server https://cloud.domain.de.
[07/30/23 17:14:47] All events are processed for repo ab0011b6-7824-4cc6-a67f-yyy.
[07/30/23 17:14:49] Repo 'Projekte' sync state transition from 'synchronized' to 'committing'.
[07/30/23 17:14:55] All events are processed for repo e93f65d2-1d4c-4062-8255-xxx.
[07/30/23 17:14:55] Repo 'Projekte' sync state transition from 'committing' to 'initializing'.
-----Change happended 30 seconds before------
[07/30/23 17:31:19] Repo 'Projekte' sync state transition from 'initializing' to 'downloading'.
[07/30/23 17:31:19] Transfer repo 'e93f65d2': ('normal', 'init') --> ('normal', 'check')
[07/30/23 17:31:19] Transfer repo 'e93f65d2': ('normal', 'check') --> ('normal', 'commit')
[07/30/23 17:31:19] Transfer repo 'e93f65d2': ('normal', 'commit') --> ('normal', 'fs')
[07/30/23 17:31:19] Transfer repo 'e93f65d2': ('normal', 'fs') --> ('normal', 'data')
[07/30/23 17:31:19] Transfer repo 'e93f65d2': ('normal', 'data') --> ('finished', 'finished')
[07/30/23 17:31:19] Repo 'Projekte' sync state transition from 'downloading' to 'synchronized'.
[07/30/23 17:31:21] Repo 'Projekte' sync state transition from 'synchronized' to 'committing'.
[07/30/23 17:31:21] All events are processed for repo e93f65d2-1d4c-4062-8255-xxx.
[07/30/23 17:31:21] Repo 'Projekte' sync state transition from 'committing' to 'synchronized'.

Hello @freezziey, you can modify the log_level field of notification section to debug in seafile.conf, so that when the client subscribes to the notification server, when the library is updated, the notification server will output the log of sending notifications to the corresponding client. You can check if a notification is sent after setting the debug log_level.

The log level debug did only reveal an error message, but when changing files there are no logs about messages sent

2023/08/04 01:57:40 path / internal server error: failed to upgrade http to websocket: websocket: the client is not using the websocket protocol: 'upgrade' token not found in 'Connection' header

2023/08/04 12:00:11 notification server started.
2023/08/04 12:05:27 failed to read json data from client: 172.18.0.1:37768: websocket: close 1006 (abnormal closure): unexpected EOF
2023/08/04 13:19:57 disconnected because no pong was received for more than 5s
2023/08/04 13:19:57 failed to read json data from client: 172.18.0.1:44600: read tcp 172.18.0.4:8083->172.18.0.1:44600: use of closed network connection

Maybe something with the websocket in thre proxy? Here my nginx config

log_format seafileformat '$http_x_forwarded_for $remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_response_time';
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}

server {
    listen       80;
    server_name  cloud.domain.com;
    root /var/www/website;
    location /.well-known/acme-challenge {
        default_type "text/plain";
        allow all;
    }
    location / {
        return 301 https://$server_name$request_uri;
    }
    #rewrite ^ https://$http_host$request_uri? permanent;    # Forced redirect from HTTP to HTTPS

    server_tokens off;      # Prevents the Nginx version from being displayed in the HTTP response header
}

server {
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/cloud.domain.com/fullchain.pem;    # Path to your fullchain.pem
    ssl_certificate_key /etc/letsencrypt/live/cloud.domain.com/privkey.pem;  # Path to your privkey.pem
    server_name cloud.domain.com;
    server_tokens off;

    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;

        proxy_set_header   X-Forwarded-Proto https;

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

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

# If you are using [FastCGI](http://en.wikipedia.org/wiki/FastCGI),
# which is not recommended, you should use the following config for location `/`.
#
#    location / {
#         fastcgi_pass    127.0.0.1:8000;
#         fastcgi_param   SCRIPT_FILENAME     $document_root$fastcgi_script_name;
#         fastcgi_param   PATH_INFO           $fastcgi_script_name;
#
#         fastcgi_param  SERVER_PROTOCOL     $server_protocol;
#         fastcgi_param   QUERY_STRING        $query_string;
#         fastcgi_param   REQUEST_METHOD      $request_method;
#         fastcgi_param   CONTENT_TYPE        $content_type;
#         fastcgi_param   CONTENT_LENGTH      $content_length;
#         fastcgi_param  SERVER_ADDR         $server_addr;
#         fastcgi_param  SERVER_PORT         $server_port;
#         fastcgi_param  SERVER_NAME         $server_name;
#         fastcgi_param   REMOTE_ADDR         $remote_addr;
#        fastcgi_read_timeout 36000;
#
#         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;

        access_log      /var/log/nginx/seafhttp.access.log seafileformat;
        error_log       /var/log/nginx/seafhttp.error.log;
    }

    location /seafdav {
        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;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_read_timeout  1200s;
        client_max_body_size 0;

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

    location /notification/ping {
        proxy_pass http://127.0.0.1:8083/ping;
        access_log      /var/log/nginx/notif.access.log;
        error_log       /var/log/nginx/notif.error.log;
    }

    location /notification {
        proxy_pass http://127.0.0.1:8083/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        access_log      /var/log/nginx/notif.access.log;
        error_log       /var/log/nginx/notif.error.log;
    }
}

the /var/log/nginx/notif.error.log is empty and the notif.access.log only shows that the client called the ping endpoint once right after start

xx.xx.xx.xx- - [04/Aug/2023:22:46:01 +0200] "GET /notification/ping HTTP/1.1" 200 16 "-" "Seafile/9.0.2 (Windows NT)"