Intermittent errors after server update to 7.1.3

After the update of the Seafile server (OS: Debian 10.3) from 7.0.4 to 7.1.3 there are frequent intermittent errors in the web interface and the Seafile client (version 7.0.7).

From /home/seafile/logs/seahub.log:
2020-04-27 11:24:26,198 [ERROR] django.request:135 handle_uncaught_exception Internal Server Error: /api/v2.1/notifications/
Traceback (most recent call last):
File “/home/seafile/seafile-server-7.1.3/seafile/lib64/python3.6/site-packages/pysearpc/utils.py”, line 30, in sendall
n = fd.send(data[offset:])
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/home/seafile/seafile-server-7.1.3/seahub/thirdpart/django/core/handlers/exception.py”, line 41, in inner
response = get_response(request)
File “/home/seafile/seafile-server-7.1.3/seahub/thirdpart/django/core/handlers/base.py”, line 244, in _legacy_get_response
response = middleware_method(request)
File “/home/seafile/seafile-server-7.1.3/seahub/seahub/auth/middleware.py”, line 33, in process_request
if request.user.is_authenticated() and not request.user.is_active:
File “/home/seafile/seafile-server-7.1.3/seahub/seahub/auth/middleware.py”, line 23, in get
request._cached_user = get_user(request)
File “/home/seafile/seafile-server-7.1.3/seahub/seahub/auth/init.py”, line 120, in get_user
user = backend.get_user(username) or AnonymousUser()
File “/home/seafile/seafile-server-7.1.3/seahub/seahub/base/accounts.py”, line 570, in get_user
user = self.get_user_with_import(username)
File “/home/seafile/seafile-server-7.1.3/seahub/seahub/base/accounts.py”, line 541, in get_user_with_import
emailuser = seaserv.get_emailuser_with_import(username)
File “/home/seafile/seafile-server-7.1.3/seafile/lib64/python3.6/site-packages/seaserv/service.py”, line 128, in get_emailuser_with_import
return ccnet_threaded_rpc.get_emailuser_with_import(email)
File “/home/seafile/seafile-server-7.1.3/seafile/lib64/python3.6/site-packages/pysearpc/client.py”, line 126, in newfunc
ret_str = self.call_remote_func_sync(fcall_str)
File “/home/seafile/seafile-server-7.1.3/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py”, line 101, in call_remote_func_sync
ret_str = transport.send(self.service_name, fcall_str)
File “/home/seafile/seafile-server-7.1.3/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py”, line 62, in send
sendall(self.pipe, header)
File “/home/seafile/seafile-server-7.1.3/seafile/lib64/python3.6/site-packages/pysearpc/utils.py”, line 32, in sendall
raise NetworkError(‘Failed to write to socket: %s’ % e)
pysearpc.errors.NetworkError: Failed to write to socket: [Errno 32] Broken pipe
2020-04-27 11:24:26,198 [ERROR] django.request:135 handle_uncaught_exception Internal Server Error: /api/v2.1/repos/

After a refresh, these errors usually go away.

UPDATE: Sorry, doesn’t but I have to correct myself. The fix provided below does NOT help.

The solution provided by powUpYM seems to fix this issue as well:

The problem persists after the update to Seafile Server 7.1.4.

I have same problem. Seafile server pro 7.1.4.

I have the same problem in Seafile pro 7.1.5

UPDATE: Sorry, not a solution either.
I might have found the fix for this problem. This thread led me to the underlying cause:

I followed the documentation (https://download.seafile.com/published/seafile-manual/deploy/using_ldap.md) in order to enable TLS for the LDAP integration.

Therefore, I created a directory disabled_libs_use_local_ones_instead here:
${SEAFILE_INSTALLATION_DIR}/seafile-server-latest/seafile/lib

Apparently, I created the directory as root. I’m sure it was readable for the seafile user. However, after changing the owner to seafile, the intermittent errors seem to be gone for good:

chown seafile:seafile disabled_libs_use_local_ones_instead

Sorry, but I have to correct myself again: While the problem seemed to be completely gone yesterday, today the same intermittent errors are back. There’s also some odd delay after logging in. I don’t know if that’s related to the cause.

Turns out, this was an embarassing mistake on my side. Apparently, a long time ago I had copied some settings in seahub_settings.py from one installation to another without correcting SITE_BASE which was still pointing to the other installation. After correcting the setting and restarting, the issue seems to be gone. This also explains the odd delay after logging in.

This is becoming a running gag but no, this didn’t fix it. Next day, the problem is back again. The issue occurs in Chrome and the Seafile client as well. FYI, I maintain three instances of Seafile server in three different locations all connected to the same LDAP. Only one of the servers suffers from this issue. The configurations are close to identical. It only started after the update from 7.0.4 to 7.1.3.

Hi cbiere,
I too am still having this issue, I’m the OP of the post you marked as solution. I’m running a dockerized version of Seafile 7.1.6 and it seems like every other day or every third day, my Seafile crashes. I run a chown on the entire Seafile data directory, and then reboot the containers, this works for a few days until it does the same thing again. I feel that I have a permissions issue but can’t find it. I changed my Seafile Docker to run as root to try to solve this, but that didn’t work either. Not sure how to proceed, for now, I have a nightly restart scripted and before the restart it does a chown on the Seafile directory, it’s not a pretty solution, but it’s worked for me thus far.

Hi SpencerXZX,

thanks for your input. I’m pretty sure the server itself is not crashing. I’m considering doing a full backup, then reinstalling everything and finally copying /home/seafile from the backup to the newly installed server. I suspect there’s something wrong with the installed Python libraries or other libraries on the system. The server is not used for anything else so it’s a straight forward installation and the issue crept in by some update.

If that doesn’t fix it, I can only imagine something wrong with the database.

Seems I found the source of the issue after all. The log messages were actually a red herring because they also appear on the other two server which didn’t have this problem.

/home/seafile/seafile-server-7.1.4/seahub/media contained a directory custom on the affected server. On the other two servers it’s a link to …/…/…/seahub-data/custom. Files and permissions were okay and identical. So after I replaced the directory with a link the problem disappeared and hasn’t reoccured.

1 Like