Kopano Core 8.5.8: A quickfix release

dw2412

Hi Walter

yes - the kopano server is running since apprx. September last year. The messages about zarafa,.clientupdatestatus just arrived with kopano-server version 8.5.8. There is no entry in logfile about this earlier than today 10:47am. I don’t know what actually provokes this messages BUT all processes on the server are kopano no single zarafa process is running.

But actually I don’t think that this is the source of all the mess. The main problem is that I cannot see the folders in my Inbox using Kopano WebApp 3.4.x but with WebApp 3.3.1 and with Outlook Zarafa Mapi Client. Only issue with Outlook Zarafa Mapi Client and the both Mailboxes in question is that I cannot even do a Properties -> General -> Foldersize. This results on both mailboxes in no data being displayed.

Andreas

Hi Andreas,

no idea, but try to run the script:
kopano-search-upgrade-findroots.py

Also start Kopano server with parameter “–restart-searches” and leaf it running for about 5 minutes.
/usr/sbin/kopano-server -F --restart-searches

May be it helps.
Walter

dw2412

Hi Walter,
did what you suggested - no change in kopano-server behaviour :-( Means my folders still being lost in webapp and outlook still not working as before the update to 8.5.8 and all this mess :-(

But here some more info about the zarafa.clientupdatestatus source issue… Just changed the level to debug before issuing the both both commands. In Logfile there is now some more info about where the message might have its start:

Sat Apr 21 21:32:15 2018: [debug ] Previous message logged 9 times
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting user 105 from external source
Sat Apr 21 21:32:15 2018: [error ] SQL [19663550] Failed: Table ‘zarafa.clientupdatestatus’ doesn’t exist, Query Size: 47, Query: “DELETE FROM clientupdatestatus where userid=105”
Sat Apr 21 21:32:15 2018: [error ] KDatabase::I_Update() query failed: “Table ‘zarafa.clientupdatestatus’ doesn’t exist”, query: DELETE FROM clientupdatestatus where userid=105
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting user 105 done. Error code 0x80000007
Sat Apr 21 21:32:15 2018: [debug ] Accepted incoming connection from file:///var/run/kopano/server.sock
Sat Apr 21 21:32:15 2018: [debug ] Previous message logged 2 times
Sat Apr 21 21:32:15 2018: [debug ] Accepted incoming connection from 127.0.0.1
Sat Apr 21 21:32:15 2018: [debug ] Accepted incoming connection from file:///var/run/kopano/server.sock
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting contact 99 from external source
Sat Apr 21 21:32:15 2018: [error ] SQL [19663550] Failed: Table ‘zarafa.clientupdatestatus’ doesn’t exist, Query Size: 46, Query: “DELETE FROM clientupdatestatus where userid=99”
Sat Apr 21 21:32:15 2018: [error ] KDatabase::I_Update() query failed: “Table ‘zarafa.clientupdatestatus’ doesn’t exist”, query: DELETE FROM clientupdatestatus where userid=99
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting contact 99 done. Error code 0x80000007

Looks like that it is autodelete related. Maybe it would make sense to look in kopano server code again - looks like that the clienupdatestatus is not fully removed…

Andreas

Andreas,

no idea, only solution to open a support request tomorrow.

Walter

dw2412

Hi Walter,

thanks for help nevertheless. Since I actually needed to have a working system again I did a kopano-backup of all mailboxes and simply recreated all user mailboxes to be sure and on safe site that the data contained is solid again - yes, that worked!.

I guess it has to do with my setup (multiserver, because of archive server in use) and regarding the both clientupdatestatus messages - actually the user was a test of creating a new account to see what happens with new stores and problems found in both other stores. With new stores the problem is not there, so after the test the user got removed and the “other” problem started… OK - I can live this this. For Auto-deleting contact 99 I have actually no idea. At least no idea why for whatever reason this contact should have ever being using a zarafa client. A contact is just a mail address without any store for my opinion… For my opinion the delete is still having its source here:

strings libkcserver.so.0.0.0|grep -i “delete from clientupdatestatus”
DELETE FROM clientupdatestatus where userid=

So the file is there and it is from Apr 20th:
-rw-r–r-- 1 root root 1792248 Apr 20 12:35 libkcserver.so.0.0.0

and came with following Ubuntu 14.04 LTS Deb File:
-rw-r–r-- 1 root root 568566 Apr 20 12:39 libkcserver0_8.5.8.2-0+27.1_amd64.deb

Maybe you Kopano Devs should have further look into this issue with the clientupdatetable thing…

Andreas

jengelh

Patch is on its way.

Today I also updated a system, database repair needs about 1 hour. It is a hosted Kopano system.
System is working and up again, Outlook sees all folders, I tested with 3 logins.
One issue, a new created user did not get an store, I need to create store manually, will look into this issue tomorrow.

Walter

dw2412

@jengelh said in Kopano Core 8.5.8: A quickfix release:

Patch is on its way.

Thanks ;-) Looks like that this will cure the issue…

Andreas

dw2412

@walterhof Maybe this is all and only related to system that is having such a database history and additionally was used all time with Mapi Client and right with kopano migration got an archiver attached (means actually multiserver because archiver is running on other server):

+-------+-------+-------+------------+------------------+---------------------+
| major | minor | micro | revision   | databaserevision | updatetime          |
+-------+-------+-------+------------+------------------+---------------------+
|     6 |    30 |     0 |      15472 |               29 | 2009-07-05 15:08:33 |
|     6 |    30 |     0 |      15545 |               29 | 2009-07-08 22:47:37 |
|     6 |    30 |     0 |      15765 |               29 | 2009-07-23 14:13:23 |
.
. Edit: shortened...
.
|     8 |     5 |     7 | 2153185280 |               68 | 2018-04-20 08:18:26 |
|     8 |     5 |     8 | 2153250816 |               69 | 2018-04-20 18:21:19 |
|     8 |     5 |     8 | 2153250816 |               70 | 2018-04-20 18:21:35 |
+-------+-------+-------+------------+------------------+---------------------+
133 rows in set (0.02 sec)

Yes - it is running more or less since the days zarafa got opensource… Got upgraded with nearly everything and anything ;-)

Andreas

Andreas,

my system started 3 years later:

+-------+-------+-------+------------+------------------+---------------------+
| major | minor | micro | revision   | databaserevision | updatetime          |
+-------+-------+-------+------------+------------------+---------------------+
|     7 |     1 |     0 |      39121 |               63 | 2012-12-22 20:16:24 |
|     7 |     1 |     0 |      40304 |               63 | 2013-01-26 16:53:07 |
 ...
|     8 |     5 |     7 | 2153185280 |               68 | 2018-04-19 19:15:46 |
|     8 |     5 |     8 | 2153250818 |               69 | 2018-04-20 18:19:33 |
|     8 |     5 |     8 | 2153250818 |               70 | 2018-04-20 18:19:33 |
+-------+-------+-------+------------+------------------+---------------------+
58 rows in set (0.02 sec)

This version should contain a database fix fur older systems.

Walter

dw2412

@walterhof so the last question is - have you kopano-archiver running with 2nd server running on other system? If I understood all the kopano-dbadm issues right the things fixed in the quickfix should be for multiserver installations. Maybe this is the clue in this story…

Andreas

Only single server installations and multi company installations but no kopano-archiver.

Walter

dw2412

With all kopano single server installations that I’m responsible for - including one with multicompany - there was no issue during the upgrades. Just 2 needed at all the use of kopano-dbadm…

Andreas

mcostan

I have a similar issue as posted in:

https://forum.kopano.io/topic/1370/error-in-kopano-core/7

I have never seen this error before 8.5.8