Solved: OSX Client shows connection error after upgrade to 6.0.3

Our OSX Client shows connection error after upgrade to 6.0.3.

applet.log:

[09/11/16 10:33:46]request failed for https://sub.domain.tld/api2/ping/: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
    <title>Page unavailable</title>
</head>
<body>
    <h1>Page unavailable</h1>

    <p>Sorry, but the requested page is unavailable due to a
    server hiccup.</p>

    <p>Our eng

The client shows the exclamantion mark but everything works as expected. Upload, download, listings in the client. Its just the server connections status which reports failure.

Anyone?

This is the error message in seahub_django_request.log

 2016-09-11 18:19:00,776 [ERROR] django.request:256 handle_uncaught_exception Internal Server Error: /api2/ping/
Traceback (most recent call last):
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/Django-1.8.10-py2.7.egg/django/core/handlers/base.py", line 132, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/Django-1.8.10-py2.7.egg/django/views/decorators/csrf.py", line 58, in wrapped_view
    return view_func(*args, **kwargs)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/Django-1.8.10-py2.7.egg/django/views/generic/base.py", line 71, in view
    return self.dispatch(request, *args, **kwargs)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/seahub/api2/base.py", line 23, in dispatch
    response = super(APIView, self).dispatch(*a, **kw)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/djangorestframework-3.3.2-py2.7.egg/rest_framework/views.py", line 466, in dispatch
    response = self.handle_exception(exc)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/seahub/api2/base.py", line 20, in handle_exception
    return super(APIView, self).handle_exception(exc)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/djangorestframework-3.3.2-py2.7.egg/rest_framework/views.py", line 454, in dispatch
    self.initial(request, *args, **kwargs)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/djangorestframework-3.3.2-py2.7.egg/rest_framework/views.py", line 378, in initial
    self.check_throttles(request)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/djangorestframework-3.3.2-py2.7.egg/rest_framework/views.py", line 340, in check_throttles
    if not throttle.allow_request(request, self):
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/seahub/api2/throttling.py", line 233, in allow_request
    return super(ScopedRateThrottle, self).allow_request(request, view)
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/seahub/api2/throttling.py", line 123, in allow_request
    self.history = self.cache.get(self.key, [])
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/Django-1.8.10-py2.7.egg/django/core/cache/backends/filebased.py", line 41, in get
    if not self._is_expired(f):
  File "/srv/www/seafile/seafile-server-6.0.3/seahub/thirdpart/Django-1.8.10-py2.7.egg/django/core/cache/backends/filebased.py", line 138, in _is_expired
    exp = pickle.load(f)
EOFError

Strange issue is that only the call of

curl https://sub.domain.tld/api2/ping/

produces the error (and the osx clients pings from time to time the server). All other api-calls work.

Removing /tmp/seahub_cache and restarting seahub solved the issue.

I’m having exactly the same problem when using the Linux client. Also removed /tmp/seahub_cache and restarted the server, but to no avail. It shows as it is disconnected, but keeps working fine until I try to refresh libraries, then it doesn’t even want to display libraries anymore…

Is there something on the client that I can do that could solve this problem?

Please check the error logs at the client first.

It took some time before it happened again… but when I looked at the logs I found something related to this issue on Github (https://github.com/haiwen/seafile-client/issues/759)… Checking which version of qt was currently installed and I recompiled the aur package, I haven’t tested it thoroughly, but it seems to be working.