Seafile Server 7.1.4 for Raspberry Pi is ready! 23.05.2020

[Bernie_O]

Thank you @jobenvil - upgrading with following your detailed instructions worked perfectly for me.

[aveltens]

I am also having trouble starting seahub after upgrading to 7.1.4:

Starting seahub at port 8000 ...                                                                                                                                                                                   
Traceback (most recent call last):                                                                                                                                                                                 
  File "/home/seafile/seafile-server-7.1.4/seahub/seahub/avatar/models.py", line 23, in <module>                                                                                                                   
    from PIL import Image                                                                                                                                                                                          
  File "/home/seafile/seafile-server-7.1.4/seahub/thirdpart/PIL/Image.py", line 93, in <module>                                                                                                                    
    from . import _imaging as core
ImportError: cannot import name '_imaging' from 'PIL' (/home/seafile/seafile-server-7.1.4/seahub/thirdpart/PIL/__init__.py)

My system:

Python 3.7.3
Kernel: 4.19.66-v7+ armv7l (32 bit) 
Distro: Raspbian GNU/Linux 10 (buster)

I installed:

seafile-server_7.1.4_pi-buster-stable.tar.gz

I tried to install Pillow to thridpart:

sudo pip3 install -U pillow -t /var/www/seafile/seafile-server-latest/seahub/thirdpart

I also tried sudo pip3 install pillow and sudo -u seafile pip3 install pillow but nothing helps.

What am I missing out?

This is my second attempt. After failing to run it on Raspian Stretch, I upgraded to Buster and installed 7.1.4_pi-buster-stable. Might there be some leftovers from the stretch attempt? If so, what do I need to clean?

[jobenvil]

@jobenvil

If you use the rpi-Buster version, you need to do some hack after you extract the rpi seafile package in your system. The python library path is hardcoded during the compilation to point to
$INSTALLDIR/seafile/lib/python3.6/site-packages in few seafile shell scripts, like seahub.sh , reset-admin.sh , setup-seafile-mysql.sh and upgrade_7.0_7.1.sh . The issue arises if you compile Seafile server with other Python version than Python 3.6. These paths still points to /python3.6/ but since the native Buster version brings Python 3.7, the directory created under
$INSTALLDIR/seafile/lib/ will be /python3.7/ instead of /python3.6/ . Therefore it must be created a symbolic soft link from python3.6 to python3.7 inside $INSTALLDIR/seafile/lib/ like “ ln -s python3.7 python3.6 ”.

@aveltens Maybe this

[aveltens]

Thanks for the quick response. My understanding is, I do not need the symlink since the directory is already named python3.6 and I did not get any errors regarding such a path issue. Or do I need the link the other way arround then ln -s python3.6 python3.7?

[jobenvil]

@aveltens

My understanding is, I do not need the symlink since the directory is already named python3.6 and I did not get any errors regarding such a path issue. Or do I need the link the other way arround then ln -s python3.6 python3.7 ?

It depends on which os you downloaded. Stretch had the directory /python3.6 and Buster /python3.7. If you still see /python3.6 it means that you have still have installed the Strech version instead of Buster, unless you renamed did earlier.

[aveltens]

oh damn, you’re right. My ansible script actually did not download the buster version, but used the cached strech download

I added the symlink and now it seams to start without error, BUT it does not seam to reach a started state:

 seahub.service - Seafile hub
   Loaded: loaded (/etc/systemd/system/seahub.service; enabled; vendor preset: enabled)
   Active: activating (start) since Mon 2020-06-01 14:35:11 CEST; 3min 2s ago

[aveltens]

Oh never mind, I just forgot to switch back to daemon=True. Everything is back to normal now. Thanks for your help and patience.

Also big thanks for your very detail initial post wich solved serveral of my inital problems / questions. Would be great if such a post is linked from the Release notes on github for the next releases.

[jobenvil]

Yes, actually there is some warning regarding the official support channel, but it could be explicitedly the indication to go to the forum to see the recomendations.

[Nogs_Noggy]

Sorry for this late answer.
I have commented out the “CACHES” part inside seahub_settings.py now. And it works now (without memcached?). I don’t know, but i think its faster then before. Weird.
Memcached is running. But you could be right. i never understood how memcached works.
Is it recommended to use on Seafile server on Raspberry Pi’s?

~ $ service memcached status
memcached.service - memcached daemon
Loaded: loaded (/lib/systemd/system/memcached.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-05-31 06:10:38 CEST; 1 day 15h ago
Docs: man:memcached(1)
Main PID: 487 (memcached)
Tasks: 10 (limit: 4915)
Memory: 4.2M
CGroup: /system.slice/memcached.service
└─487 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1

~ $ memcached -V
memcached 1.5.6

Thank you very much for your help!

[Bernie_O]

@Nogs_Noggy

I have commented out the “CACHES” part inside seahub_settings.py now. And it works now (without memcached?). I don’t know, but i think its faster then before. Weird.

I never used memcached in my installations, because I read somewhere that it was only recommended, if more than 50 people access the webinterface simultaneously. This is not the case for my installations. For updating to 7.1.4 I now had to install the memcached modules (otherwise the upgrade-Script wouldn’t run), but I also noticed that with memcached backend activated in seahub_settings.py the installations were slower than before. So I commented out the memcached Settings in seahub_settings.py and again noticed a speed gain.

[jobenvil]

I had the same experience. Thanks @Bernie_O to share with us

[Bordersun]

Many thanks for this work !

[aveltens]

@jobenvil

Yes, actually there is some warning regarding the official support channel, but it could be explicitedly the indication to go to the forum to see the recomendations.

I noticed that, but I was not going to raise an issue, just upgrading my Seafile instance. So I followed the linked upgrade guide, not being aware of relevant info in this place here.

[nihilistaX]

How did you see a slowdown with memcached enabled? You mean slower webui?
I didn’t notice that, but i don’t see real difference in loading ui, with or without memcached.
Maybe its because my device is bit faster? Its an odroid hc1 with armbian buster…

[Bernie_O]

@nihilistaX

You mean slower webui?

The cache is only for seahub. Yes, a slower webui.
I don’t think this has to do with the performance of devices.

[ksbn]

@jobenvil

RTFM (I took the expresion from @jaeti01) You can imagine what it means. If not, Read The *** Manual.

Hi all, the referenced manual is not existing, can you please check @jobenvil ?
Thanks a lot and a happy new year!
Cheers

[jobenvil]

HNY! sure @ksbn https://manual.seafile.com/upgrade/upgrade_notes_for_7.1.x/

[fret]

When I try to start seahub, I get the following error:

LC_ALL is not set in ENV, set to en_US.UTF-8
./seahub.sh: line 210: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
Starting seahub at port 8000 …
Traceback (most recent call last):
File “/opt/seafile/seafile-server-8.0.3/check_init_admin.py”, line 19, in
from seaserv import ccnet_api
ModuleNotFoundError: No module named ‘seaserv’

Could not find anything on the net :-/