17. December 2013

Debian – upgrade from Apache 2.2 to 2.4 – Starting web server: apache2 failed!

Debian maintainers changed default Apache from version 2.2 to 2.4. Not a big deal?

I was just upgrading one package and it had dependency on whole new Apache. I said yes to upgrade, because I had no bigger issues with Apache upgrade in past.

Wohoo. This upgrade was very funny, because Apache 2.4 was not able to start due to conflicting configurations. The coolest part was that Subversion stopped working, but that’s different story.

The problematic part was that Apache failed to start with nice message:

[FAIL] Starting web server: apache2 failed!
[warn] The apache2 instance did not start within 20 seconds. Please read the log files to discover problems ... (warning)

I checked the log file /var/log/apache2/error.log, but there was no hint what went wrong.

Apache was working even though startup script reported error. :-)

After a while I found that there were some important changes in /etc/apache2/apache2.conf. I compared this file with /etc/apache2/apache2.conf.dpkg.dist.

It was necessary to update following lines in apache2.conf:

Mutex file:${APACHE_LOCK_DIR} default
#LockFile /var/lock/apache2/accept.lock - disable this, old value

Then it was possible to start Apache without problem:

[ ok ] Restarting web server: apache2.

29. September 2012

Plone upgrade – Clear and Rebuild failed

Plone is not working very well when portal_catalog is not up-to-date. This happens after upgrades. It is recommended to go to portal_catalog, section Advanced and run: Clear and Rebuild.

I did this, but after few seconds I’ve got this fancy error:

Module ZPublisher.Publish, line 126, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 46, in call_object
Module Products.CMFPlone.CatalogTool, line 460, in manage_catalogRebuild
Module plone.app.discussion.patches, line 45, in patchedClearFindAndRebuild
Module Products.ZCatalog.ZCatalog, line 287, in manage_catalogClear
Module Products.ZCatalog.Catalog, line 102, in clear

If you dig deep down into ZCatalog code, then you’ll see that some objects in DB simply don’t have clear method. Those objects are typically some ancient instances of TextIndex or instance of some long dead product.

Solution is to catch this error and remove those old grumpy objects from DB. Here is small patch:

    def clear(self):
        """ clear catalog """

        self.data = IOBTree()  # mapping of rid to meta_data
        self.uids = OIBTree()  # mapping of uid to rid
        self.paths = IOBTree()  # mapping of rid to uid
        self._length = BTrees.Length.Length()
        to_delete = []

        for index in self.indexes.keys():
                LOG.error('unclearable object %s. ' % str(index))

        for del_index in to_delete:
            LOG.error('Removing from index %s. ' % str(del_index))
            del self.indexes[del_index]

Remove eggs/Products.ZCatalog-2.13.23-py2.7.egg/Products/ZCatalog/Catalog.pyc file to avoid caching. Start the Plone and run Clear and Rebuild function. Watch log file also for error messages from ZCatalog.

29. September 2012

Plone buildout problem – We already have zc.buildout

If you want to upgrade Plone just with buildout, then you may find following funny error:

 Loading extensions.
 Error: There is a version conflict.
 We already have: zc.buildout 1.5.2

Typical cause of this problem is that your bin/buildout is out of date. Solution is simple. Remove bin directory. Download latest version of bootstrap.py and let it generate new version of bin/buildout for you. Run biuldout again :)

wget http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
python bootstrap.py

10. October 2011

Debian Testing 64bit – php5-gd – libjpeg version Unknown

I found strange issue with php5-gd during upgrade of Linux Debian Testing.

php5-gd package is responsible for rendering and manipulation of images in PHP apps. Problem was that after installation phpinfo() displayed weird message:

libjpeg version: unknown

No JPEG manipulation was working. I found Sergio’s solution for 32 bit version of Debian Linux. The trick is in replacing some so files from Suse.

Here is updated version for Debian 64bit:

cd /tmp
wget ftp://ftp.icm.edu.pl/vol/rzm1/linux-opensuse/distribution/11.3/repo/oss/suse/x86_64/php5-gd-5.3.2-1.31.x86_64.rpm
alien php5-gd-5.3.2-1.31.x86_64.rpm
dpkg -i php5-gd_5.3.2-2.31_amd64.deb
cp /usr/lib64/php5/extensions/gd.so /usr/lib/php5/20090626/

wget ftp://ftp.icm.edu.pl/vol/rzm1/linux-opensuse/distribution/11.3/repo/oss/suse/x86_64/libpng14-14-1.4.3-2.1.x86_64.rpm
alien -d libpng14-14-1.4.3-2.1.x86_64.rpm
dpkg -i libpng14-14_1.4.3-3.1_amd64.deb
mv /usr/lib64/libpng14.so* /usr/lib

/etc/init.d/apache2 restart

6. October 2011

Debian – dpkg problem – tar exists on unknown argument —warning=no-timestamp

I was upgrading Linux Debian. Everything went ok until the upgrade of dpkg.

After upgrading dpkg package I was not able to install anything, because of error with tar command.

Tar was complaining that –warning=no-timestamp is unknown parameter and program terminated with error.

So I made small trick. I renamed /bin/tar to /bin/tar.original:

mv /bin/tar /bin/tar.original

Then I wrote simple script into /bin/tar file:


tar.original xf -

Add permission:

chmod a+x /bin/tar

The last step is reinstallation of broken packages:

apt-get install --reinstall dpkg
apt-get install --reinstall tar