SOLVED: Seafile 7.0.10 Search index won't update

Firstly the file search worked after updating from Seafile v6.3 to v7.0. Then I noticed (sometine between v7.0.4 und v7.0.6) that the newer Files were not being indexed and therefor could not be found. After alle the tips here in the forum (clearing index & updating etc.) it nows seems that I have a empty index.

In seafile the search results are always empty.

Even tried using a extern elasticsearch server, brings no results.

I’ve also tested:
mysql-db with ""mysqlcheck -u root -p --all-databases --auto-repair
&
REPOs with “./seaf-fsck.sh”

no errors found.

System ist a aktual Ubuntu 18.04 LTS. + Java 8.

Does anybody have a idea why i can’t update the search index?

Here ist the LOG File from “./pro//pro.py search --update”

Hey Chris.Piel,
I am sorry I would like to help you but may I ask you first for some more information? Can you please check the following, then I will most likely be capable to say what the problem is:

Here are my questions:

  • ubuntu 18.04 + java 8. How much ram did your machine has?
  • how did you start seafile? Did you start it with systemd or with seafile.sh start and seahub.sh start? If it is systemd please post your seafile.service
  • please post netstat -tulpn. Are there entries with the port 9200 and 9300?
  • here is what should happen. Please confirm what happens and what not:
  1. you start seafile
  2. after some seconds a elasticsearch.pid file is created in seafile-dir/pids
  3. watch the pid number inside this file. Is this pid always the same or does it change after a while?
  4. what is posted in seafile-dir/logs/elasticsearch.log. Can you see something like that? What happens after the initializing? Does some errors occur or does it end with
[2019-11-11T06:37:50,537][INFO ][o.e.n.Node               ] [] initializing ...
... what happens here ...
[2019-11-11T08:31:54,454][INFO ][o.e.g.GatewayService     ] [qToqAXT] recovered [2] indices into cluster_state
[2019-11-11T08:31:57,046][INFO ][o.e.c.r.a.AllocationService] [qToqAXT] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[repo_head][2]] ...]).
  1. please check ps aux | grep java. Is there only one java process or are the two or more? It should look like

root@seafile-demo:/home/seafile/logs# ps aux | grep java seafile 1626 1.3 37.1 3201428 760380 ? Sl 08:31 0:30 /usr/bin/java -Xms512m -Xmx1g -XX:-AssumeMP -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch -server -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -Djdk.io.permissionsUseCanonicalPath=true -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j.skipJansi=true -XX:+HeapDumpOnOutOfMemoryError -Des.path.home=/home/seafile/seafile-pro-server-7.0.10/pro/elasticsearch -cp /home/seafile/seafile-pro-server-7.0.10/pro/elasticsearch/lib/* org.elasticsearch.bootstrap.Elasticsearch -Epath.logs=/home/seafile/logs -Epath.data=/home/seafile/pro-data/search/data -Enetwork.host=127.0.0.1 -p /home/seafile/pids/elasticsearch.pid root 3921 0.0 0.0 15792 936 pts/0 S+ 09:10 0:00 grep --color=auto java

If you could answer me these questions I am quite sure I will be capable to tell you where the problem is.

Best regards
Christoph

I am testing seafile deployment on buster with the OS java jdk 11. Do we still have to stay with a very old java version for the file search to work properly?

Hello Christoph,

As I was gathering the information that you asked for and comparing the jave process options with yours, I discoverd that mine was corrupt. After I corerct the configuation und a seafile restart, I was able to update the Index with no errors. I have no Idea where or how the configutation got corrupted, it seemed to work at least, PID and java process started.

Thanks for your help.

regards
Chris

Hello there,

I do have this error and I’m still working on its resolution based on this topic and this one Elasticsearch not running after upgrade to 7.0.8 (from 6.2.4)

So far, I can’t find any document in seafile using the search field after upgrading to version 7.1.14 from version 7.0.17.

I’ve followed all recommendation and procedures mentioned in official documentation and I’m still not able to find any document and still have the same error message running

./pro//pro.py search --update

What can I do next to fix this issue?

I’m running seafile PRO on SLES 15 based on CenOS binaries using a jdk 1.8 and python 3.6.12 as a minimum version of python 3.5 is mandatory for seafile 7.1

Hey everybody,
I addition to my first recommendation how to solve elasticsearch problems if elasticsearch does not start. Here is a short guideline how to fix elasticsearch problems if elasticsearch seems to start but there is no search results available in seafile.

1) change ownership

the elasticsearch indexes are located at “your-seafile-directory/pro-data/search/data/nodes/0”. Please make sure that all files below pro-data belong to the seafile user. I would try: “chown -R seafile: your-seafile-directory/pro-data”. After that try to restart seafile.

2) try to manually index the files

change to the seafile user and try to start the indexing process

sudo su seafile
cd your-seafile-directory/seafile-server-latest/pro/
./pro.py search --update

3) try to clear the cache via seafile

sudo su seafile
cd your-seafile-directory/seafile-server-latest/pro/
./pro.py search --clear
./pro.py search --update

4) If all this does not work I would try to delete the elasticsearch index and to recreate

sudo su seafile
rm -R your-seafile-directory/pro-data/ search/data
./pro.py search --update

If these does not solve your problems, your problem is very specific and you should get more information from the log files.
There might be a problem with your SQL-Alchemy version. There is a incompatibility with newest SQLAlchemy 1.4 as Seafile pro 7.1 requires SQLAlchemy 1.3.You can force using SQLAlchemy 1.3 using the following command:

pip3 install SQLAlchemy==1.3.8

Best regards
Christoph

Hi Christoph,

The SQLAlchemy downgrade fixed the issue.

Thank you for the help!