New batches of errors since upgrading

Caldwell

I’m getting errors like this since upgrading to the latest z-push. These errors are filling the log file every TWO seconds.

[WARN] [user@domain] /usr/share/z-push/backend/kopano/importer.php:146 mapi_importcontentschanges_config() expects parameter 3 to be long, string given (2)
18/09/2017 23:58:07 [48150] [WARN] [user@domain] StatusException: ImportChangesICS->Config(): Error, mapi_import_*_changes_config() failed: 0xFFFFFFFF80070057 - code: 12 - file: /usr/share/z-push/backend/kopano/importer.php:152
18/09/2017 23:58:07 [48150] [WARN] [user@domain] Ignored incoming change, global status indicates problem.

I’ve not found anything in search engines to indicate what is causing this problem.

Any ideas or help?

Sebastian

This code are wasn’t changed. Could you enable the wbxml log and post what is going on in general?

Manfred

Hi Caldwell,

did you also update Kopano?

Manfred

fbartels

Hi @caldwell ,

can you tell us which version of Kopano and Z-Push you are using?

Caldwell

Zarafa
Product version: 7,2,4,28
File version: 28

z-push-common.noarch 2.3.8+0-73.1

Perhaps this version doesn’t play nicely with Zarafa?

Manfred

Hi Caldwell,

it should actually work, but we didn’t test the latest Z-Push versions with Zarafa.

Does it happen for every user? Do you also have WBXML log?

Manfred

Caldwell

@manfred

I turned on “LOGLEVEL_WBXML” in the conf file. Nothing seems to have changed in the output. This is what I get for, it appears, every user:

20/09/2017 13:48:00 [ 6490] [WARN] [user@domain] /usr/share/z-push/backend/kopano/importer.php:146 mapi_importcontentschanges_config() expects parameter 3 to be long, string given (2)
20/09/2017 13:48:00 [ 6490] [WARN] [user@domain] StatusException: ImportChangesICS->Config(): Error, mapi_import_*_changes_config() failed: 0xFFFFFFFF80070057 - code: 12 - file: /usr/share/z-push/backend/kopano/importer.php:152
20/09/2017 13:48:00 [ 6490] [WARN] [user@domain] Ignored incoming change, global status indicates problem.

Manfred

Hi Caldwell,

it looks like the z-push-error.log. What’s in z-push.log?

Manfred

Caldwell

@manfred

The z-push.log has been empty since the upgrade. Same settings obviously in z-push conf file. I’ve restarted apache multiple times and removed the zero byte z-push.log file. Nothing changes. It’s not logging ANYTHING there.

Manfred

Hi Caldwell,

did you change LOGBACKEND, LOGFILEDIR or LOGFILE in config.php of z-push? Has the webserver user permissions to write to the log file? Are there any errors in apache log?

Manfred

Caldwell

@manfred

No. They are the same. The only changed thing in the config is 1-2 new sections added by this version of z-push. Everything else is the same:

define('LOGBACKEND', 'filelog');
define('LOGFILEDIR', '/var/log/z-push/');
define('LOGFILE', LOGFILEDIR . 'z-push.log');

I tried also doing specialLogUsers, but that doesn’t work either. The users certainly exist, but it’s not writing anything.

Permissions are apache.apache / 644. Same as the error log, which it writes to just fine. Nothing has changed there either.

This thing is screwed up since the upgrade, as far as new errors and no logging.

No errors in apache worth mentioned from what I can see.

Manfred

Hi Caldwell,

do you have SELinux enabled? Maybe there are some its restrictions in place? It is strange that Z-Push is able to write to the error log, but not the regular log.

Manfred

Caldwell

No. It’s set as “Permissive” and not “Enforcing” on that server currently. The only change that was made was a yum update to pick up the new z-push.

How can I downgrade to the previous version?