Ben,

I'm seeing the following errors in messages.log

Jun  2 20:36:11 pdebrabander httpd[19349]: {PHP} Using Twig_Autoloader is deprecated since version 1.21. Use Composer instead. at /usr/share/php/Twig/Autoloader.php#30

Jun  2 20:36:11 pdebrabander httpd[19349]: {PHP} Using Twig_Autoloader is deprecated since version 1.21. Use Composer instead. at /usr/share/php/Twig/Autoloader.php#30

Jun  2 20:36:43 pdebrabander httpd[19347]: {PHP} Using Twig_Autoloader is deprecated since version 1.21. Use Composer instead. at /usr/share/php/Twig/Autoloader.php#30

Jun  2 20:36:43 pdebrabander httpd[19347]: {PHP} Using Twig_Autoloader is deprecated since version 1.21. Use Composer instead. at /usr/share/php/Twig/Autoloader.php#30

Ben Chambers wrote:

The upstream RH patch to PHP has hit our repos...very interested in feedback to all who had issues.

If it hasn't updated your system already, you can install with:

yum upgrade php

I would suggest restart Apache:

service httpd restart

B

Received the bugreport update from RH today and already in the repos !! Great news.
I Will be testing and hope it solves the problem.

Dependencies Resolved



================================================================================

 Package        Arch     Version                Repository                 Size

================================================================================

Updating:

 php            x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   1.4 M

Updating for dependencies:

 php-cli        x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   2.7 M

 php-common     x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   563 k

 php-enchant    x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified    41 k

 php-gd         x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   126 k

 php-ldap       x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified    51 k

 php-mbstring   x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   503 k

 php-mysql      x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified    99 k

 php-pdo        x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified    97 k

 php-process    x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified    54 k

 php-soap       x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   157 k

 php-xml        x86_64   5.4.16-36.1.el7_2.1    clearos-centos-verified   124 k



Transaction Summary

================================================================================

Upgrade  1 Package (+11 Dependent packages)

The upstream RH patch to PHP has hit our repos...very interested in feedback to all who had issues.

If it hasn't updated your system already, you can install with:

yum upgrade php

I would suggest restart Apache:

service httpd restart

B

This bug is also effecting Owncloud.
When you try to upload a file through the webbrowser, this is not working.
After a restart of the HTTPS server it is possible again to upload.

BTW
status has been changed at bug report:

What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |VERIFIED

Just for info. The ticketnumber has been changed:

Bugzilla 1323643

Status : ON_QA

Looks promissing

Yes, that does look promising...and yes again...we would get the patched PHP update almost as soon as when RH released it.

B

This is looking very promossising : Title

Priority: high → urgent.

Does this mean that this will also be solved for ClearOS ?

So...we're kind of stuck here.

Zarafa won't fix because it's pointed to a fault upstream in PHP's libraries. RHEL (upstream) is not showing any urgency to backport the patch or move to an updated version of PHP where the problem is resolved, which would have forced Zarafa (in the event of an upgrade) to re-roll their packages.

I tried Remi's PHP repos and while the upgrade goes fine, before you go down that path, don't.

The kicker is php-mapi, a PHP extension that Zarafa requires for Webapp, webaccess and MAPI support. It requires to be compiled on the same version of PHP, and it's not available for 5.6.19.

First, I can't find source for the latest php-mapi (it may not even be available from Zarafa), but even if we did, Pete says:

The nasty bit will be excluding php-X packages from the CentOS repo. Lots of third party PHP modules (like php-mapi) use the "php-" prefix, so we can't do the usual yum exclude entry, i.e. php-*

So...no hope? Note quite...Another Pete quote...of someone else's quote from the original bug report:

felipe, the problem is that if mod_php.so doesn't actually get unloaded (usually
because of circular references in another extension) then the
php_rfc1867_callback global stays pointing to the previous value on the next
MINIT which means now php_session_rfc1867_orig_callback will point to it as well
and we are hosed. I think gxd305's approach is correct.

Pete sees hope in this comment, meaning if we stop/start Apache, it should avoid this situation.

A hack job you say? You bet. But unless someone has a better idea, this might get us by for the time.

For those that are having constant issues, try adding a cron job in the early morning hours:

/usr/bin/systemctl stop httpd.service

/usr/bin/systemctl start httpd.service

And let us know if you either don't see the issue anymore or can solve the issue manually stop/starting the service, that's be great.

If it works, we plan on releasing an update that will add this cron job automatically with the log rotate.

B.

Hm very strange that you can't reproduce it, for me the problem begins definitively with zarafa 7.2.1, installed WebApp is 2.1.2. And i have 2-3 machines (one with business and one with home edition) where i have installed a similar constellation. Every time the same problem occurs.

Standarderrors in the logs are:

ownCloud[5057]: {user_ldap} Attempt for Paging? 1
ownCloud[5059]: {user_ldap} Error when searching: Bad search filter code -7

Than, when i first upload something in OwnCloud (with the Webinterface, not the Desktop-Client) OR WebApp (Attachment) the log shows:

MAPI error: 80040102 (method: zif_mapi_msgstore_getreceivefolder, line: 2603)
php-mapi[27198]: php-mapi shutdown
httpd[5041]: php-mapi shutdown

And than after some time the segmentation fault error starts. It takes some days if i can't upload anything and i have to restart the httpd. My temp solution is to make a cron job to restart the httpd daemon every night:

0 3 * * * root service httpd restart > /dev/null 2>&1

Looking forward for the php fix.

Hi guys,

Such a strange one. I cannot reproduce it on either our 'dogfood' mail server or my development environment. I think in this thread or another, I did see the segfault once...that was using webaccess (not webapp) for Zarafa, and even that went away once I upgrade to 7.2.1.

The issue that is stalling us isn't so much around pushing out a PHP package, incorporating the patch suggested in the bug report...it's the ongoing maintenance of the package once we make a change...essentially, we own the maintenance on that version until such time as we can get back onto RHEL/CentOS mainstream. When will that be? Impossible to say.

If it was affecting everyone, we'd have no choice...,but it seems discretionary for some reason.

Let me talk to Pete on Tuesday...he has a far better sense how long thing take upstream with this type of bug. Ideally, an update would soon be released to centos test repos that we could then provide through ClearOS's repos to those afflicted. Eventually, update would move through to mainstream updates. If Pete's feeling is that's not going to happen in a reasonable amount of time, I guess we have to look at compiling and packaging our own PHP RPM's and perhaps just keep them in a test repo unless we start getting reports that this is wide spread.

More to come.

B

Nick Howitt wrote:

I'm also a bit nervous. To find the php files do a "yum list php*" and you'll see which repos they're in. You should come up with a similar list of files to my one linked below. Almost certainly these are not the webconfig-php files as they run in a sandboxed environment.

I''ve managed to compile the Oracle srpm and the results are here. Note that compiling a single source generated lots of rpm's so I don't know if you need them all or if you can get by with the single rpm. It may call for the others as dependencies.

The other thing I don't know is if ClearOS apply their own patches to any of the packages and I don't know if any other ClearOS packages depend on these.

I would hope, that if it is a just a minor patch as Oracle did, then ClearOS could do the same.

I do all my 7.x stuff on a VM but I don't run it properly and have nothing to test. I also don't use Zarafa at all.

@ Ben, Peter

Can you please respond to this, before we break some servers.....

I'm also a bit nervous. To find the php files do a "yum list php*" and you'll see which repos they're in. You should come up with a similar list of files to my one linked below. Almost certainly these are not the webconfig-php files as they run in a sandboxed environment.

I''ve managed to compile the Oracle srpm and the results are here. Note that compiling a single source generated lots of rpm's so I don't know if you need them all or if you can get by with the single rpm. It may call for the others as dependencies.

The other thing I don't know is if ClearOS apply their own patches to any of the packages and I don't know if any other ClearOS packages depend on these.

I would hope, that if it is a just a minor patch as Oracle did, then ClearOS could do the same.

I do all my 7.x stuff on a VM but I don't run it properly and have nothing to test. I also don't use Zarafa at all.

Nick Howitt wrote:

The easy part of his suggestion is to download the compiled package from here. Then try installing it. Oracle Linux seems to be based on RHEL so this *may* work. I suggest before you do this you download the original ClearOS version of php first as a backup.

I've tried his other route or recompiling the sources but I'm going to have to install a load of dependencies before that will work.

Unfortunately i don't have a test server, so i'm a liitle anxious to try this.
Are the clearos PHP located in http://mirror.clearfoundation.com/clearos/7.2.0/updates/x86_64/RPMS/ and are this the webconfig-php-* files ?

The easy part of his suggestion is to download the compiled package from here. Then try installing it. Oracle Linux seems to be based on RHEL so this *may* work. I suggest before you do this you download the original ClearOS version of php first as a backup.

I've tried his other route or recompiling the sources but I'm going to have to install a load of dependencies before that will work.

Hi,

I've received an email from a guy as a reaction on the RH bugreport whoe was trying to help.
The only thing is that i do not have enough knowledge to try this.
Maybe some can help with.

this is what he wrote to me:

Just search google for php-5.4.16-36.0.1.el7_1.src.rpm — that should take you straight to public-yum.oracle.com and you’ll also see the bug fix advisory that went with it. You can rebuild the source or extract just the patch and add it into your own source rpm.

If you look around public-yum.oracle.com you’ll find the binaries as well and you should be able to install those without any trouble (apart from needing to ignore the signature).

If you need help with the rpm building or installation it’s probably best to ask on the ClearOS lists

Ben,

Please see the last post on RH support : Title
Can you assist in this, because this is out of my league.

I'm willing to test it, but need help to apply the patch.

Ben Chambers wrote:

I'm not sure how prioritization works upstream, but perhaps if you add yourself to the RH bug tracker list on this bug report it will help to push the issue to the top for resolution.

B.

Hello Ben,

Is it not possible within ClearOS to upgrade to another PHP version ?
There are plenty releases after the release date of version 5.4.16 on 09 May 2013 ;-)

Or, is it possible to use the patch as mentioned on the RH bug tracker: Title

And how do you apply this patch ?

I'm not sure how prioritization works upstream, but perhaps if you add yourself to the RH bug tracker list on this bug report it will help to push the issue to the top for resolution.

B.

Ben Chambers wrote:

Looks like this isn't a Zarafa bug, but one in PHP...the Zarafa bug report was filed here

ClearOS 7 users PHP 5.4.16...the PHP fix is in 5.4.20.

Not sure what we can do here...I'll ask around at today's developer meeting.

This would explain also the user who reported a similar issue in ownCloud...that shoud have been a big pointer to all of us to look for something common...like PHP.

B.

Look promissing.

My current PHP version is indead 5.4.16.
Maybe an PHP upgrade is possible

Looks like this isn't a Zarafa bug, but one in PHP...the Zarafa bug report was filed here

ClearOS 7 users PHP 5.4.16...the PHP fix is in 5.4.20.

Not sure what we can do here...I'll ask around at today's developer meeting.

This would explain also the user who reported a similar issue in ownCloud...that shoud have been a big pointer to all of us to look for something common...like PHP.

B.

Unfortunately it failed today to upload an attachement again.
Restarted the Apache server and everything worked again.

The only errors found in httpd/error.log

[Tue Mar 15 10:59:23.538531 2016] [core:notice] [pid 683] AH00052: child pid 30501 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:24.539631 2016] [core:notice] [pid 683] AH00052: child pid 26097 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:24.539686 2016] [core:notice] [pid 683] AH00052: child pid 24123 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:26.541819 2016] [core:notice] [pid 683] AH00052: child pid 22648 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:27.542917 2016] [core:notice] [pid 683] AH00052: child pid 23431 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:29.547004 2016] [core:notice] [pid 683] AH00052: child pid 25818 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:29.547082 2016] [core:notice] [pid 683] AH00052: child pid 25804 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:31.553524 2016] [core:notice] [pid 683] AH00052: child pid 25797 exit signal Segmentation fault (11)

[Tue Mar 15 10:59:31.553595 2016] [core:notice] [pid 683] AH00052: child pid 24125 exit signal Segmentation fault (11)

Same problem for me, i have installed zarafa 7.2.1 two or three months ago, it runs well. I can’t exactly determine when the problem begins, but since a few weeks, every 5-7 days the problem occurs and i can’t upload anything in zarafa (attachment) and owncloud. So i have to restart the webserver every week. In the httpd error log i found lot’s of „AH00052: child pid exit signal Segmentation fault“ errors. They appear since installation of 7.2.1. And now the zarafa-gateway service failed, when installing the new clearos packages.

The gateway service is failing now:

Job for zarafa-gateway.service failed because the control process exited with error code. See "systemctl status zarafa-gateway.service" and "journalctl -xe" for details.

A zarafa-condrestart is not working and the service is stopped.

Mar 10 19:55:31 pdebrabander systemd: Stopped LSB: Zarafa Collaboration Platform's POP3/IMAP Gateway.

Mar 10 19:55:34 pdebrabander systemd: Starting LSB: Zarafa Collaboration Platform's POP3/IMAP Gateway...

Mar 10 19:55:34 pdebrabander zarafa-gateway: Starting zarafa-gateway: [fatal  ] Config error: Unknown option 'ssl_enable_v2' found!

Mar 10 19:55:34 pdebrabander zarafa-gateway: [MISLUKT]

Mar 10 19:55:34 pdebrabander systemd: zarafa-gateway.service: control process exited, code=exited status=1

Mar 10 19:55:34 pdebrabander systemd: Failed to start LSB: Zarafa Collaboration Platform's POP3/IMAP Gateway.

Mar 10 19:55:34 pdebrabander systemd: Unit zarafa-gateway.service entered failed state.

Disabled the log timestamp in gateway.cfg and it restarted again.

# Log timestamp - prefix each log line with timestamp in 'file' logging mode

log_timestamp	=	1

#ssl_enable_v2 = yes

Ben Chambers wrote:

For anyone coming across this thread...I've included the upgrade script that fixes Zarafa's broken RPM's to app-zarafa version 2.1.22. It's located /usr/clearos/apps/zarafa/deploy/zarafa-7.2.0.48204-cleanup, but you don't have to run it manually...it will run (via cron) after the upgrade is complete automatically.

Interested to know if a) this fixes attachments (both webaccess and webapp) and if you guys are seeing any other issue as a result of the upgrade.

I performed some tests yesterday going from the default Zarafa on a newly installed ClearOS 7 to the upgraded 7.2.1 and things went well. If we get some more positive feedback, it will let me feel better about moving the entire 7.2.1 in to the core repos.

Thx.

B

Ben,

i noticed that with me not all packages were upgrade, so i did this manually.

zarafa-compat upgrade noymaly
zarafa-presence did not

# ENABLE_BETA=True yum --disablerepo=clearos-epel upgrade zarafa-presence

Geladen plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

Loading mirror speeds from cached hostfile

 * clearos: clearos.mirrors.ovh.net

 * clearos-centos: download2.clearsdn.com

 * clearos-centos-updates: download2.clearsdn.com

 * clearos-contribs: clearos.mirrors.ovh.net

 * clearos-contribs-paid: mirror1-london.clearos.com

 * clearos-contribs-paid-testing: mirror1-london.clearos.com

 * clearos-fast-updates: download2.clearsdn.com

 * clearos-infra: clearos.mirrors.ovh.net

 * clearos-updates: clearos.mirrors.ovh.net

 * private-clearcenter-dyndns: download2.clearsdn.com:80

 * private-clearcenter-zarafa-community: download4.clearsdn.com:80

 * private-clearcenter-zarafa-community-testing: download2.clearsdn.com:80

Oplossen van afhankelijkheden

--> Transactiecontrole uitvoeren

---> Pakket zarafa-presence.x86_64 0:7.2.0.48204-211.1 wordt bijgewerkt

---> Pakket zarafa-presence.x86_64 0:7.2.1.51838-319.2 wordt een update

--> Klaar met oplossen afhankelijkheden



Afhankelijkheden opgelost



================================================================================================================================================================================

 Package                             Arch                       Versie                                   Repository                                                       Grootte

================================================================================================================================================================================

Bijwerken:

 zarafa-presence                     x86_64                     7.2.1.51838-319.2                        private-clearcenter-zarafa-community-testing                      14 k



Transactie Samenvatting

================================================================================================================================================================================

Upgrade  1 Pakket



Totale grootte: 14 k

Is this ok [y/d/N]: y

Downloading packages:

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

  Bijwerken               : zarafa-presence-7.2.1.51838-319.2.x86_64                                                                                                        1/2

/var/tmp/rpm-tmp.wiYqP4: regel 1: fg: geen taakbesturing

fout: %preun(zarafa-presence-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-presence-7.2.0.48204-211.1.x86_64

  Verifiëren              : zarafa-presence-7.2.1.51838-319.2.x86_64                                                                                                        1/2

  Verifiëren              : zarafa-presence-7.2.0.48204-211.1.x86_64                                                                                                        2/2



Bijgewerkt:

  zarafa-presence.x86_64 0:7.2.1.51838-319.2



Mislukt:

  zarafa-presence.x86_64 0:7.2.0.48204-211.1

In some ways possibly miles O/T, but I had problems when a script of mine was untar'ing into /tmp and it trampled all over the /tmp permissions. It brought down my postfix mail server until one of the devs diagnosed it.

I have noticed this to be the same problem with OWNCLOUD as well... have to reboot to make it to where you can upload files again... both Zarafa and Owncloud seem to go hand in hand with this issue.

That sounds like the /tmp directory is getting full or misbehaving in some other way. The /tmp folder gets tidied up on a reboot, so there's a temporary reprieve.

Ben Chambers wrote:

For anyone coming across this thread...I've included the upgrade script that fixes Zarafa's broken RPM's to app-zarafa version 2.1.22. It's located /usr/clearos/apps/zarafa/deploy/zarafa-7.2.0.48204-cleanup, but you don't have to run it manually...it will run (via cron) after the upgrade is complete automatically.

Interested to know if a) this fixes attachments (both webaccess and webapp) and if you guys are seeing any other issue as a result of the upgrade.

I performed some tests yesterday going from the default Zarafa on a newly installed ClearOS 7 to the upgraded 7.2.1 and things went well. If we get some more positive feedback, it will let me feel better about moving the entire 7.2.1 in to the core repos.

Thx.

B

I installed a good bit of updates last night... think this fix was included...

Question: should I change the upload_tmp_dir = /var/lib/zarafa-webapp/tmp/ back to the default?

I have noticed this to be the same problem with OWNCLOUD as well... have to reboot to make it to where you can upload files again... both Zarafa and Owncloud seem to go hand in hand with this issue.

For anyone coming across this thread...I've included the upgrade script that fixes Zarafa's broken RPM's to app-zarafa version 2.1.22. It's located /usr/clearos/apps/zarafa/deploy/zarafa-7.2.0.48204-cleanup, but you don't have to run it manually...it will run (via cron) after the upgrade is complete automatically.

Interested to know if a) this fixes attachments (both webaccess and webapp) and if you guys are seeing any other issue as a result of the upgrade.

I performed some tests yesterday going from the default Zarafa on a newly installed ClearOS 7 to the upgraded 7.2.1 and things went well. If we get some more positive feedback, it will let me feel better about moving the entire 7.2.1 in to the core repos.

Thx.

B

Hi Ben,

Upgrade succesfully executed.

[root@pdebrabander tmp]# ./upgrade.sh

Checking zarafa-dagent

Removing older version of zarafa-dagent

Checking zarafa-gateway

Removing older version of zarafa-gateway

Checking zarafa-ical

Removing older version of zarafa-ical

Checking zarafa-monitor

Removing older version of zarafa-monitor

Checking zarafa-search

Checking zarafa-presence

Checking zarafa-server

Removing older version of zarafa-server

Checking zarafa-spooler

Removing older version of zarafa-spooler

Checking zarafa-search-plus

Removing older version of zarafa-search-plus

Restarting zarafa services

Restarting zarafa-dagent (via systemctl):                  [  OK  ]

Restarting zarafa-server (via systemctl):                  [  OK  ]

Restarting zarafa-gateway (via systemctl):                 [  OK  ]

Restarting zarafa-ical (via systemctl):                    [  OK  ]

Restarting zarafa-monitor (via systemctl):                 [  OK  ]

Restarting zarafa-spooler (via systemctl):                 [  OK  ]

Restarting zarafa-search (via systemctl):                  [  OK  ]

I'll test the system for a couple of days and let you know the results.

I forgot that Zarafa had some packaging bugs in their 7.2.0.48204 RPM's...You'll need to run the script below.

#!/bin/bash



PACKAGES="zarafa-dagent zarafa-gateway zarafa-ical zarafa-monitor zarafa-search zarafa-presence zarafa-server zarafa-spooler zarafa-search-plus"

RESTART=0



for pkg in $PACKAGES

        do

        echo "Checking $pkg"

        CHECK=`rpm -qa --queryformat "%{VERSION}|" $pkg`

        if [[ "$CHECK" == *"7.2.0.48204"* ]]; then

            # Are we upgrading to 7.2.1???

            if [[ "$CHECK" == *"7.2.1"* ]]; then

                echo "Removing older version of $pkg"

                rpm -e --nodeps --noscripts $pkg-7.2.0.48204

                RESTART=1

            fi

        fi

done



if [[ "$RESTART" == 1 ]]; then

    echo "Restarting zarafa services"

    /usr/sbin/zarafa-condrestart

fi

Copy to /tmp/

chmod 755 /tmp/upgrade.sh

/tmp/upgrade.sh

I'll get this script put into the app-zarafa upgrade script soon so that we can automatically upgrade users through software updates.

B.

I forgot that Zarafa had some packaging bugs in their 7.2.0 RPM's...You'll need to run this script (attached).

Copy to /tmp/

chmod 755 /tmp/upgrade.sh

/tmp/upgrade.sh

I'll get this script put into the app-zarafa upgrade script soon so that we can automatically upgrade users through software updates.

B.

Ben Chambers wrote:

@Patrick,

When running 7.2.0 and using Webaccess, I can confirm, on upload I created the same seg faults in the log file:

 AH00052: child pid 22174 exit signal Segmentation fault (11)

Can you confirm that you are using webaccess?

Your solution is to either use Zarafa webapp, or, upgrade to 7.2.1 (see my prior post), as this upgrade resolves the issue and will let you use webaccess if that is preferred.

B.

Hello ben,

I'm not using webaccess at all.
Just tried to upgrade to 7.2.1, but it looks like it didn't succeeded.

  Opruimen                : zarafa-server-packages-7.2.0.48204-211.1.x86_64                              42/63

  Opruimen                : zarafa-webaccess-7.2.0.48204-211.1.x86_64                     43/63

/var/tmp/rpm-tmp.HvyJ2O: regel 1: fg: geen taakbesturing

error: %preun(zarafa-dagent-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-dagent-7.2.0.48204-211.1.x86_64

error: zarafa-dagent-7.2.0.48204-211.1.x86_64: erase failed

/var/tmp/rpm-tmp.zsICZG: regel 1: fg: geen taakbesturing

error: %preun(zarafa-spooler-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-spooler-7.2.0.48204-211.1.x86_64

  Opruimen                : zarafa-utils-7.2.0.48204-211.1.x86_64                               44/63

error: zarafa-spooler-7.2.0.48204-211.1.x86_64: erase failed

  Wissen                  : zarafa-libarchiver-7.2.0.48204-211.1.x86_64                       45/63

  Opruimen                : zarafa-contacts-7.2.0.48204-211.1.x86_64                      46/63

  Opruimen                : php-mapi-7.2.0.48204-211.1.x86_64                                 47/63

/var/tmp/rpm-tmp.Oh7GxH: regel 1: fg: geen taakbesturing

error: %preun(zarafa-server-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-server-7.2.0.48204-211.1.x86_64

  Opruimen                : python-mapi-7.2.0.48204-211.1.x86_64                               48/63

error: zarafa-server-7.2.0.48204-211.1.x86_64: erase failed

  Opruimen                : zarafa-common-7.2.0.48204-211.1.x86_64                          49/63

  Wissen                  : zarafa-base-7.2.0.48204-211.1.x86_64                                  50/63

  Opruimen                : zarafa-webaccess-lang-7.2.0.48204-211.1.x86_64               51/63

/var/tmp/rpm-tmp.rFNdTP: regel 1: fg: geen taakbesturing

error: %preun(zarafa-search-plus-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-search-plus-7.2.0.48204-211.1.x86_64

  Opruimen                : zarafa-client-7.2.0.48204-211.1.x86_64                    52/63

error: zarafa-search-plus-7.2.0.48204-211.1.x86_64: erase failed

/var/tmp/rpm-tmp.SSoz20: regel 1: fg: geen taakbesturing

error: %preun(zarafa-gateway-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-gateway-7.2.0.48204-211.1.x86_64

error: zarafa-gateway-7.2.0.48204-211.1.x86_64: erase failed

/var/tmp/rpm-tmp.oAMIEc: regel 1: fg: geen taakbesturing

error: %preun(zarafa-ical-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-ical-7.2.0.48204-211.1.x86_64

error: zarafa-ical-7.2.0.48204-211.1.x86_64: erase failed

/var/tmp/rpm-tmp.GLstJo: regel 1: fg: geen taakbesturing

error: %preun(zarafa-monitor-7.2.0.48204-211.1.x86_64) scriptlet failed, exit status 1

Error in PREUN scriptlet in rpm package zarafa-monitor-7.2.0.48204-211.1.x86_64

  Opruimen                : zarafa-7.2.0.48204-211.1.x86_64                        53/63

zarafa-condrestart

Restarting zarafa-dagent (via systemctl):  Warning: zarafa-dagent.service changed on disk. Run 'systemctl daemon-reload' to reload units.

                                                           [  OK  ]

Restarting zarafa-server (via systemctl):  Warning: zarafa-server.service changed on disk. Run 'systemctl daemon-reload' to reload units.

                                                           [  OK  ]

Restarting zarafa-gateway (via systemctl):  Warning: zarafa-gateway.service changed on disk. Run 'systemctl daemon-reload' to reload units.

                                                           [  OK  ]

Restarting zarafa-ical (via systemctl):  Warning: zarafa-ical.service changed on disk. Run 'systemctl daemon-reload' to reload units.

                                                           [  OK  ]

Restarting zarafa-monitor (via systemctl):  Warning: zarafa-monitor.service changed on disk. Run 'systemctl daemon-reload' to reload units.

                                                           [  OK  ]

Restarting zarafa-spooler (via systemctl):  Warning: zarafa-spooler.service changed on disk. Run 'systemctl daemon-reload' to reload units.

                                                           [  OK  ]

Restarting zarafa-search (via systemctl):  Warning: zarafa-search.service changed on disk. Run 'systemctl daemon-reload' to reload units.

@Patrick,

When running 7.2.0 and using Webaccess, I can confirm, on upload I created the same seg faults in the log file:

 AH00052: child pid 22174 exit signal Segmentation fault (11)

Can you confirm that you are using webaccess?

Your solution is to either use Zarafa webapp, or, upgrade to 7.2.1 (see my prior post), as this upgrade resolves the issue and will let you use webaccess if that is preferred.

B.

Ben Chambers wrote:

Hi guys,

I think there might be some confusion being created here by the Zarafa terminology.

Zarafa ships with two separate frameworks.

1. Webapp

Accessible at https://<IP>/webapp

2. Webaccess

Accessible at https://<IP>/webaccess

Webapp supercedes Webaccess...in fact, I'm not even sure if webaccess is being developed on any longer. I think you should definitely be using /webapp in vesion 7.2.

My tests indicated that the upload of attachments if you are using webaccess does require you to change /etc/php.ini and set upload_tmp_dir = /var/lib/zarafa-webaccess/tmp/.

However, using webapp, I could not produce any issues and it works 'out of the box'.

Another thing I noticed in my testing is that there is a Zarafa bug in Webaccess 7.2.0 and can send your CPU load through the roof in some scenarios...as it happens, my test environment met those credentials and I was not even able to login using webaccess until I upgrade Zarafa to their suggested 7.2.1 fix.

In ClearOS, 7.2.1 is currently in the test repos...to upgrade:

ENABLE_BETA=True yum --disablerepo=clearos-epel upgrade zarafa

Once I did that, webaccess performed better and I was able to login and duplicate the attachment issue you guys noted in this thread. Updating php.ini resolved that, but that seems like a strange override (eg. PHP could use that tmp for any application not just Zarafa).

I think my recommendation would be to use webapp going forward, without any change required to your php.ini config files.

Perhaps users who posted on this thread could confirm if they were actually having the issue in Webaccess and the title (WebApp) is misleading.

B

Hi Ben,

I'm only using WebApp 7.2.2 and DeskApp.0.10 on multiple computers/users

I could try what webaccess is doing for testing.

The upgrade i'll try later on tonight.

Peter Baldwin wrote:

Are there any clues in the /var/log/httpd/error_log?

Peter,

This the only thing what i've found in the error.log

on Mar 07 14:17:27.836375 2016] [core:notice] [pid 20253] AH00052: child pid 14285 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:28.838870 2016] [core:notice] [pid 20253] AH00052: child pid 14286 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:30.845528 2016] [core:notice] [pid 20253] AH00052: child pid 14287 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:31.846626 2016] [core:notice] [pid 20253] AH00052: child pid 14288 exit signal Segmentation fault (11)

Mon Mar  7 14:17:33 2016: [error  ] M4LMsgServiceAdmin::ConfigureMsgService() MSGServiceEntry failed 80040115

[Mon Mar 07 14:17:49.868514 2016] [core:notice] [pid 20253] AH00052: child pid 14290 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:49.868586 2016] [core:notice] [pid 20253] AH00052: child pid 14291 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:53.876376 2016] [core:notice] [pid 20253] AH00052: child pid 14292 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:53.876441 2016] [core:notice] [pid 20253] AH00052: child pid 14293 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:56.883769 2016] [core:notice] [pid 20253] AH00052: child pid 14289 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:56.883844 2016] [core:notice] [pid 20253] AH00052: child pid 14364 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:58.890604 2016] [core:notice] [pid 20253] AH00052: child pid 14613 exit signal Segmentation fault (11)

[Mon Mar 07 14:17:58.890665 2016] [core:notice] [pid 20253] AH00052: child pid 14615 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:01.899665 2016] [core:notice] [pid 20253] AH00052: child pid 14614 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:01.899737 2016] [core:notice] [pid 20253] AH00052: child pid 14625 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:03.903862 2016] [core:notice] [pid 20253] AH00052: child pid 14628 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:03.904007 2016] [core:notice] [pid 20253] AH00052: child pid 14629 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:06.913654 2016] [core:notice] [pid 20253] AH00052: child pid 14630 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:06.913724 2016] [core:notice] [pid 20253] AH00052: child pid 14631 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:08.917486 2016] [core:notice] [pid 20253] AH00052: child pid 14632 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:08.917554 2016] [core:notice] [pid 20253] AH00052: child pid 14633 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:11.927356 2016] [core:notice] [pid 20253] AH00052: child pid 14638 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:11.927427 2016] [core:notice] [pid 20253] AH00052: child pid 14640 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:13.931592 2016] [core:notice] [pid 20253] AH00052: child pid 14641 exit signal Segmentation fault (11)

[Mon Mar 07 14:18:13.931660 2016] [core:notice] [pid 20253] AH00052: child pid 14642 exit signal Segmentation fault (11)

After a restart of the HTTPS server, i could use the attachements again

Hi guys,

I think there might be some confusion being created here by the Zarafa terminology.

Zarafa ships with two separate frameworks.

1. Webapp

Accessible at https://<IP>/webapp

2. Webaccess

Accessible at https://<IP>/webaccess

Webapp supercedes Webaccess...in fact, I'm not even sure if webaccess is being developed on any longer. I think you should definitely be using /webapp in vesion 7.2.

My tests indicated that the upload of attachments if you are using webaccess does require you to change /etc/php.ini and set upload_tmp_dir = /var/lib/zarafa-webaccess/tmp/.

However, using webapp, I could not produce any issues and it works 'out of the box'.

Another thing I noticed in my testing is that there is a Zarafa bug in Webaccess 7.2.0 and can send your CPU load through the roof in some scenarios...as it happens, my test environment met those credentials and I was not even able to login using webaccess until I upgrade Zarafa to their suggested 7.2.1 fix.

In ClearOS, 7.2.1 is currently in the test repos...to upgrade:

ENABLE_BETA=True yum --disablerepo=clearos-epel upgrade zarafa

Once I did that, webaccess performed better and I was able to login and duplicate the attachment issue you guys noted in this thread. Updating php.ini resolved that, but that seems like a strange override (eg. PHP could use that tmp for any application not just Zarafa).

I think my recommendation would be to use webapp going forward, without any change required to your php.ini config files.

Perhaps users who posted on this thread could confirm if they were actually having the issue in Webaccess and the title (WebApp) is misleading.

B

Are there any clues in the /var/log/httpd/error_log?

Patrick de Brabander wrote:

Hi,

I'm having the same problem, but after restarting the Apache server i can upload the attachements again.
The problem is that this problem comes back again after a short period.

Currently running with WebApp 2.2.0.

Did the change in php.ini worked ?

Same here. I have to reboot to upload any files through Zarafa WebApp and Owncloud. Very inconvenient when in a rush and it does not work.

Anyone know of a permanent fix?

I am wondering what I paid for for HOME 7.0... thought it was supposed to be stable.

Hi,

I'm having the same problem, but after restarting the Apache server i can upload the attachements again.
The problem is that this problem comes back again after a short period.

Currently running with WebApp 2.2.0.

Did the change in php.ini worked ?