kopano-search start up error
nickh last edited by nickh
Every time I start kopano-search I get the following in my search.log:
2019-08-26 14:08:03,491 - search - ERROR - Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/kopano/log.py", line 103, in log_exc try: yield File "/usr/lib/python2.7/site-packages/kopano_search/__init__.py", line 393, in incremental_sync new_state = self.server.sync(importer, self.state, log=self.log) File "/usr/lib/python2.7/site-packages/kopano/server.py", line 853, in sync return _ics.sync(self, self.mapistore, importer, state, max_changes, window=window, begin=begin, end=end, stats=stats) File "/usr/lib/python2.7/site-packages/kopano/ics.py", line 253, in sync exporter.Config(stream, flags, importer, restriction, None, None, 0) File "/usr/lib/python2.7/site-packages/MAPICore.py", line 1346, in Config def Config(self, *args): return _MAPICore.IExchangeExportChanges_Config(self, *args) MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)
It happens on both systems I am using, including the one running the pure kopano 8.7.5 release from the Kopano-Core repo.
Search still seems to work and e-mail receicved after starting kopano-search appear to be indexed in that a search succeeds.
My /etc/kopano/search.cfg is the default:
[root@ClearOS7-Community ~]# sed -e '/#.*$/d' -e '/^$/d' /etc/kopano/search.cfg index_path = /var/lib/kopano/search/ limit_results = 1000 server_bind_name = file:///var/run/kopano/search.sock ssl_private_key_file = /etc/kopano/search/privkey.pem ssl_certificate_file = /etc/kopano/search/cert.pem log_method = file log_file = /var/log/kopano/search.log log_timestamp = 1 term_cache_size = 64M index_processes = 1 index_attachments = no index_attachment_max_size = 5M
Although I will mention that the certificates /etc/kopano/search/privkey.pem,
/etc/kopano/search/cert.pem and /etc/kopano/ssl/search.pem (the default sslkey_file) do not exist. But, if I point them all to the gateway CA and certificates it makes no difference.
From another post I’ve seen, I can confirm that kopano-server is correctly binding tp tcp:236.
This post is deleted!
genesis74 last edited by genesis74
I experienced a quite similar behaviour on my system. In the end the line
File "/usr/lib/python2.7/site-packages/kopano/ics.py", line 253, in sync
led me to trying to set
enable_enhanced_ics = yes
in server.cfg. On my system the issue was resolved with that step. Why? I don’t have any clue since I was unable to find any closer description of what ICS is.
Would be interested if that resolves the issue on your system, too.
Did some searching again. In fact, ics.py seems to deal with calendar items while the ics parameter in server.cfg is somehow related to caching as far as I understand this. However - setting the mentioned parameter worked for me.
Unfortunately mine is already set to yes.
did you try to connect to kopano-server via socket?
server_socket = file:///var/run/kopano/server.sock
I’ve just tried enabling it and enabling
server_pipe_name = /var/run/kopano/server.sockin server.cfg (which I assume had to be done at the same time) and then restarting but it made no difference.
thctlo last edited by
check the rights on var/run/kopano/server.sock
i’ll bet its root:root and your running kopano:kopano
Everything in /var/run/kopano is kopano:kopano including server.sock and search.sock
Looking at the users I see:
[root@microserver ~]# kopano-cli --list-users User list for Default (4): User Full Name Homeserver Store ------------------------------------------------------------------------------------------------ SYSTEM SYSTEM Kopano 8962FFEFFB7B4D639BC5967C4BB58234 test1 test1 test1 Kopano 1300B1D4844B479DADEB761401E0479F test3 test3 test3 Kopano 8CFDBB16AAEE478590CFC17F1A09152D testusertestuser password123 Kopano 8E4FB4CF16CE4735B365234B55319634
I have only created 2, test1 and test3. Should the others (especially testusertestuser) be there?
Unfortunately mine is already 32M.
@nickh, is your kopano-server connecting to the mysql-server via TCP or socket?
TCP on port 3308 (non-standard) and it is a MariaDB server.
genesis74 last edited by genesis74
@nickh, you could also try to connect to the database server via socket (i.e. in server.cfg: mysql_socket = /var/run/mysqld/mysqld.sock) if both are on the same machine. The combination of rising max_allowed_packet and using the mysql_socket solved the issue on my system (Ubuntu 18.04).
Brilliant. MariaDB is running in a sandbox on port 3308 and it means its socket file is different from standard (/var/lib/system-mysql/mysql.sock). That sorted it.
Hmm. It looks like it always happens if you stop/restart kopano-server while kopano-search is running. This means you have to stop kopano-search before stopping kopano-server and start it after starting kopano-server. This is not very workable.
Either the unit files need to be linked by dependencies or the two processes need to be run with a single command. It can be scripted but messy. For a condrestart you’d get something like:
#!/bin/sh set SEARCH-RESTART="" systemctl is-active kopano-search -q if [ $? -eq 0 ]; then systemctl stop kopano-search set SEARCH-RESTART='yes' fi systemctl condrestart kopano-server if [ -n "$SEARCH-RESTART" ]; then systemctl start kopano-search fi
A restart would be similar.
I always do it that way because if I stop kopano-server I always get errors in search.log like (I cut the long part)
MAPI.Struct.MAPIErrorNotFound: MAPI error 8004010F (MAPI_E_NOT_FOUND)
I did not find any recommendation in the docs but I think kopano-server should always be the last to be stopped and the first to be startet (even though kopano-server logs
[error ] Error while connecting to search on "file:///var/run/kopano/search.sock"
when kopano-search ist not running. Which is obvious ;-)