Unable to bind to port 236
-
@fbartels the kopano-search process is running
â kopano-search.service - Kopano Core Search Engine Loaded: loaded (/lib/systemd/system/kopano-search.service; disabled; vendor preset: enabled) Active: active (running) since Tue 2018-01-16 10:43:18 CET; 9min ago Docs: man:kopano-search(8) man:kopano-search.cfg(5) Main PID: 3685 (python2) CGroup: /system.slice/kopano-search.service ââ3685 python2 /usr/sbin/kopano-search -F ââ3689 python2 /usr/sbin/kopano-search -F
but in the search.log are this errors:
2018-01-16 10:53:24,132 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5) 2018-01-16 10:53:30,599 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5) 2018-01-16 10:53:37,066 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=3/5) 2018-01-16 10:53:43,528 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=4/5) 2018-01-16 10:53:49,989 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=5/5) 2018-01-16 10:53:56,396 - index0 - ERROR - Too many retries, skipping change 2018-01-16 10:53:56,459 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=0/5) 2018-01-16 10:54:02,922 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5) 2018-01-16 10:54:09,394 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5) 2018-01-16 10:54:15,852 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=3/5) 2018-01-16 10:54:22,308 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=4/5) 2018-01-16 10:54:28,777 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=5/5)
I found with some researches a small explanation on https://kb.kopano.io/display/WIKI/MAPI+error+codes
of the error code 0x80040115:MAPI_E_NETWORK_ERROR
but this says me nothing.
Ive seen in this forum entry that you ask in a nearly similar behaviour for this output:
The red marked area shows the line which is comming and leaving and comming and leaving. All other lines stay the whole time.Also my spamd.log gives me nearly the same error:
File "/usr/lib/python2.7/dist-packages/kopano/ics.py", line 104, in ImportMessageChange item.mapiobj = _utils.openentry_raw(mapistore, entryid.Value, 0) File "/usr/lib/python2.7/dist-packages/kopano/utils.py", line 74, in openentry_raw return _openentry_helper(mapistore, entryid, flags | MAPI_MODIFY) File "/usr/lib/python2.7/dist-packages/kopano/utils.py", line 68, in _openentry_helper return mapistore.OpenEntry(entryid, IID_IECMessageRaw, flags) File "/usr/lib/python2.7/dist-packages/MAPICore.py", line 605, in OpenEntry return _MAPICore.IMsgStore_OpenEntry(self, cbEntryID, lpInterface, ulFlags) MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)
Under the folder /var/run/kopano are these files:
servername.dbf4700-10197 prio.sock search.pid search.pid.lock server.pid server.sock
so it locks as the search service gets the false name. Do you know how i can change this?
Is this a configuration which is changed between the the releases 8.4.90.1513_0+172 and 8.5.80.77_0+188 ? -
Hi,
could you please show us your search.cfg ? -
@anotherandy thaths my search.cfg
############################################################## # INDEXED SEARCH SERVICE SETTINGS # Location of the index files index_path = /var/lib/kopano/search/ # run as specific user #run_as_user = kopano # run as specific group #run_as_group = kopano # control pid file #pid_file = /var/run/kopano/search.pid # run server in this path (when not using the -F switch) #running_path = /var/lib/kopano # Limit the number of results returned (0 = don't limit) limit_results = 1000 ############################################################## # CONNECTION TO STORAGE SERVER SETTINGS # # Socket to find the connection to the storage server. # Use https to reach servers over the network #server_socket = file:///var/run/kopano/server.sock # Login to the storage server using this SSL Key #sslkey_file = /etc/kopano/ssl/search.pem # The password of the SSL Key #sslkey_pass = replace-with-server-cert-password ############################################################## # LISTEN SETTINGS # # binding address # To setup for multi-server, use: http://0.0.0.0:port or https://0.0.0.0:port server_bind_name = file:///var/run/kopano/search.sock # File with RSA key for SSL, used then server_bind_name uses https ssl_private_key_file = /etc/kopano/search/privkey.pem # File with certificate for SSL, used then server_bind_name uses https ssl_certificate_file = /etc/kopano/search/cert.pem ############################################################## # LOG SETTINGS # Logging method (syslog, file) log_method = file # Loglevel (0(none), 1(crit), 2(err), 3(warn), 4(notice), 5(info), 6(debug)) #log_level = 3 # Logfile for log_method = file, use '-' for stderr log_file = /var/log/kopano/search.log # Log timestamp - prefix each log line with timestamp in 'file' logging mode log_timestamp = 1 ############################################################## # ADVANCED INDEXED SEARCH SETTINGS # Back end search engine (currently only xapian is supported) #search_engine = xapian # Size of indexing cache (used for indexing only, not for searching) term_cache_size = 64M # Ignore properties upon indexing # Only override this setting to expand the list #index_exclude_properties = 007D 0064 0C1E 0075 678E 678F # Number of indexing processes used during initial indexing # Setting this to a higher value can greatly speed up initial indexing, # especially when attachments are indexed. index_processes = 1 # Index drafts folder #index_drafts = yes # Index junk folder #index_junk = yes # Prepare search suggestions ("did-you-mean?") during indexing # This takes up a large percentage of the used disk space #suggestions = yes ############################################################## # ATTACHMENT INDEX SETTINGS # Should attachments be indexed index_attachments = no # Maximum file size for attachments index_attachment_max_size = 5M
Can i see anywhere a default server.cfg without to install it on a server, then i could compare it with mine?
-
@bmwfan you can find the default server.cfg in /usr/share/doc/kopano/example-config
-
@fbartels thank you. I’ve compared it but there is no difference at the search_socket in server.cfg.
Had anyone another idea?
-
Hi, have you checked the file system permissions?
an what says
#netstat -taupen - is maybe another “zombie” blocking port 236? -
@anotherandy only the kopano-server is binded to the port 236
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 0 88914202 624/master tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 0 88913099 347/slapd tcp 0 0 127.0.0.1:2501 0.0.0.0:* LISTEN 0 88911860 260/perl tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 113 88914619 635/amavisd-new (ma tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 0 88914341 624/master tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 109 88913829 484/mysqld tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 102 88912615 276/systemd-resolve tcp 0 0 0.0.0.0:236 0.0.0.0:* LISTEN 0 89006970 736/kopano-server tcp 0 0 85.25.192.248:80 118.185.246.237:15354 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:62374 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:28077 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:28453 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:2433 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:5735 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:24878 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:59915 SYN_RECV 0 0 - tcp 0 0 85.25.192.248:80 118.185.246.237:4121 SYN_RECV 0 0 - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 88912901 301/sshd tcp 0 0 85.25.192.248:22 47.186.75.15:46731 ESTABLISHED 0 91557796 8125/sshd: root [pr tcp 0 0 127.0.0.1:389 127.0.0.1:37400 ESTABLISHED 110 89147103 347/slapd tcp 0 0 85.25.192.248:22 178.249.80.48:56795 ESTABLISHED 0 91548127 8064/sshd: root@not tcp 0 0 127.0.0.1:34418 127.0.0.1:389 ESTABLISHED 999 89008115 736/kopano-server tcp 0 0 127.0.0.1:34416 127.0.0.1:389 ESTABLISHED 999 89008113 736/kopano-server tcp 0 0 127.0.0.1:34424 127.0.0.1:389 ESTABLISHED 999 89008837 736/kopano-server tcp 0 0 127.0.0.1:389 127.0.0.1:34414 ESTABLISHED 110 89008112 347/slapd tcp 0 52 85.25.192.248:22 178.249.80.48:56851 ESTABLISHED 0 91556526 8110/sshd: root@pts tcp 0 0 127.0.0.1:389 127.0.0.1:34416 ESTABLISHED 110 89008114 347/slapd tcp 0 0 127.0.0.1:389 127.0.0.1:34420 ESTABLISHED 110 89008503 347/slapd tcp 0 0 85.25.192.248:22 178.249.80.48:52766 ESTABLISHED 0 88915113 652/sshd: root@nott tcp 0 0 127.0.0.1:389 127.0.0.1:34424 ESTABLISHED 110 89008838 347/slapd tcp 0 0 127.0.0.1:34412 127.0.0.1:389 ESTABLISHED 999 89008103 736/kopano-server tcp 0 0 127.0.0.1:34420 127.0.0.1:389 ESTABLISHED 999 89008502 736/kopano-server tcp 0 0 127.0.0.1:389 127.0.0.1:34418 ESTABLISHED 110 89008116 347/slapd tcp 0 0 127.0.0.1:37400 127.0.0.1:389 ESTABLISHED 999 89147102 736/kopano-server tcp 0 0 127.0.0.1:389 127.0.0.1:37408 ESTABLISHED 110 89147243 347/slapd tcp 0 0 85.25.192.248:22 178.249.80.48:52933 ESTABLISHED 0 89003191 675/sshd: root@pts/ tcp 0 0 85.25.192.248:22 178.249.80.48:55793 ESTABLISHED 0 90831492 5567/sshd: root@not tcp 0 0 127.0.0.1:389 127.0.0.1:34412 ESTABLISHED 110 89008104 347/slapd tcp 0 0 127.0.0.1:37408 127.0.0.1:389 ESTABLISHED 999 89147242 736/kopano-server tcp 0 0 127.0.0.1:34414 127.0.0.1:389 ESTABLISHED 999 89008111 736/kopano-server tcp6 0 0 :::25 :::* LISTEN 0 88914203 624/master tcp6 0 0 :::389 :::* LISTEN 0 88913100 347/slapd tcp6 0 0 ::1:10024 :::* LISTEN 113 88914620 635/amavisd-new (ma tcp6 0 0 :::5355 :::* LISTEN 102 88912618 276/systemd-resolve tcp6 0 0 :::80 :::* LISTEN 0 89517296 2944/apache2 tcp6 0 0 :::2003 :::* LISTEN 0 89014987 833/kopano-dagent udp 0 0 0.0.0.0:5355 0.0.0.0:* 102 88912614 276/systemd-resolve udp 0 0 127.0.0.53:53 0.0.0.0:* 102 88912613 276/systemd-resolve udp6 0 0 :::5355 :::* 102 88912617 276/systemd-resolve
Permissions to which folder exactly?
I’am not sure if its depending on permissions. The server.cfg reference to the file:///var/run/kopano/search.sock but there is now one with exactly this name:
dagent.pid servername.3411a700-3967 prio.sock search.pid search.pid.lock server.pid server.sock
-
It looks like the search is not starting correct.
What shows the search.log ? -
@anotherandy in the 5th post you can see the asked output.
-
ok - the folder /var/lib/kopano/search/ belongs to the user kopano?
also /var/lib/kopano ?have you tried to clean the folder and restart the search? If you have vmware snapshot the vm before doing this.
And - sounds stupid, but did you reboot the machine? -
@anotherandy thank you, the permissions are the same. The group and the owner is kopano (755).
I’ve cleaned the search folder and rebooted the machine with no result.I`ve changed now the search log level to 6 (debug). Many index entrys are running over the screen until these entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000. When these entryid is there then the MAPI Errors begins.
2018-01-22 19:49:25,920 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F4501000000050000005AA0C047B2434A8C8D710000D392503600000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402783A01000000, docid 126306 2018-01-22 19:49:25,952 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F4501000000050000001C00CC2D3E314C3C95C7F592B26F485900000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402743A01000000, docid 126297 2018-01-22 19:49:25,979 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228 2018-01-22 19:49:25,993 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=0/5) 2018-01-22 19:49:26,448 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228 2018-01-22 19:49:26,456 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=1/5) 2018-01-22 19:49:27,304 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228 2018-01-22 19:49:27,313 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=2/5) 2018-01-22 19:49:28,971 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228 2018-01-22 19:49:28,980 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=3/5) 2018-01-22 19:49:32,230 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228 2018-01-22 19:49:32,238 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=4/5) 2018-01-22 19:49:38,688 - index0 - DEBUG - store A497753E7B1B4CE3894BB06ABB7C1F45, folder 203: new/updated document with entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000, sourcekey 1C244D94A69B4E8CA4F9CB245BF4D402523A01000000, docid 126228 2018-01-22 19:49:38,696 - index0 - WARNING - Received a MAPI error or timeout (error=0x80040115, retry=5/5) 2018-01-22 19:49:45,102 - index0 - ERROR - Too many retries, skipping change
Ive searched the entryid in the whole log and found these message:
2018-01-22 19:29:06,669 - index0 - ERROR - could not process change for entryid 00000000A497753E7B1B4CE3894BB06ABB7C1F450100000005000000A83C9472B9D046E6B89FE57F34DA9B3800000000 ([SPropValue(0x65E00102, '\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02R:\x01\x00\x00\x00'), SPropValue(0x30080040, 2017/02/03 20:07:12 GMT), SPropValue(0x65E20102, '\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02\xdez\x03\x00'), SPropValue(0x65E10102, '\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02\x02\x01\x00\x00\x00\x00'), SPropValue(0x65E30102, '\x14\x1c$M\x94\xa6\x9bN\x8c\xa4\xf9\xcb$[\xf4\xd4\x02\xdez\x03\x00'), SPropValue(0x0FFF0102, '\x00\x00\x00\x00\xa4\x97u>{\x1bL\xe3\x89K\xb0j\xbb|\x1fE\x01\x00\x00\x00\x05\x00\x00\x00\xa8<\x94r\xb9\xd0F\xe6\xb8\x9f\xe5\x7f4\xda\x9b8\x00\x00\x00\x00'), SPropValue(0x67AA000B, False), SPropValue(0x0E070003, 3L), SPropValue(0x0FFA0102, '\xa4\x97u>{\x1bL\xe3\x89K\xb0j\xbb|\x1fE'), SPropValue(0x67110003, 126228L), SPropValue(0x67150003, 203L)]):
What kind of index is this and how can i fix this?
I thought i could reindex easily my user and then should the error go away, but also this is not functioning:
kopano-search --reindex=MyUser Traceback (most recent call last): File "/usr/sbin/kopano-search", line 7, in <module> sys.exit(kopano_search.main()) File "/usr/lib/python2.7/dist-packages/kopano_search/__init__.py", line 419, in main service.reindex() File "/usr/lib/python2.7/dist-packages/kopano_search/__init__.py", line 406, in reindex with closing(kopano.client_socket(self.config['server_bind_name'], ssl_cert=self.config['ssl_certificate_file'])) as s: File "/usr/lib/python2.7/dist-packages/kopano/service.py", line 266, in client_socket s.connect(addr2) File "/usr/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 2] No such file or directory
@fbartels have you perhaps any idea?
-
Can nobody help me or has further tips?
-
I’m sorry no other idea from here.
Maybe on sunday afternoon ~ 3 p.m. we can chat and try to find a solution together? -
@anotherandy thank you. This would be really cool.
-
Today i had a chat with AnotherAndy which gaves me some tips. @AnotherAndy Thanks for that
I would update now here the “diary” perhaps someone had then further ideas.In my server log are these entries:
Sun Feb 4 15:55:16 2018: [error ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory Sun Feb 4 15:55:16 2018: [error ] SerializeObject failed with error code 0x80000002 for object 24020 Sun Feb 4 15:55:22 2018: [error ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory Sun Feb 4 15:55:22 2018: [error ] SerializeObject failed with error code 0x80000002 for object 24020 Sun Feb 4 15:55:29 2018: [error ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory Sun Feb 4 15:55:29 2018: [error ] SerializeObject failed with error code 0x80000002 for object 24020 Sun Feb 4 15:55:35 2018: [error ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory Sun Feb 4 15:55:35 2018: [error ] SerializeObject failed with error code 0x80000002 for object 24020 Sun Feb 4 15:55:42 2018: [error ] K-1562: cannot open attachment "/var/lib/kopano/attachments/2/16/1762.gz": No such file or directory Sun Feb 4 15:55:42 2018: [error ] SerializeObject failed with error code 0x80000002 for object 2402
Perhaps the MAPI Service is searching for that?
In the time when iam overtaking the database and attachments from my old zarafa installation to the new Kopano installation there was no file under /var/lib/zarafa/attachments/2/16/ which is called 1762.gz .
Is there a way to find the dependencies between the attachments and MAPI and delete this in the database?Best Regards
Daniel
-
Hi @bmwfan ,
since you know the filename, which includes the
instanceid
you could look up thehierarchyid
of the attachment in thesingleinstances
table in the database. Based on thehierarchyid
you can then identify the mapi object the attachment belongs to in theproperties
table. But you should not delete it directly from the database, instead you should then locate the email with e.g. WebApp and delete the message from there.An alternative and easier approach is to just create an empty gz archive with the name the server wants to lookup.
-
Thank you @fbartels.
How can i identify in the webapp which mails belongs to the not available attachments?Regards
Daniel
-
@bmwfan said in Unable to bind to port 236:
How can i identify in the webapp which mails belongs to the not available attachments?
By using search? From the properties table you will learn details such as subject, recipients/sender, body etc.