Month: October 2010

gnome-web-photo, Ubuntu and “Could not get gre path!”

Another issue I came across in my current adventures in gnome-web-photo land was that gnome-web-photo just stopped running after upgrading up through four different Ubuntu releases. gnome-web-photo crapped out with an error message about the GRE path being wrong, and the only resources on the web were commit messages from when the error message was changed and committed to the gnome-web-photo project.

Digging, digging and a bit more digging led me to suspecting that xulrunner wasn’t behaving as it should. stracing the gnome-web-photo binary (named gnome-web-photo.real on Ubuntu, as gnome-web-photo is a simple wrapper script) revealed that it was attempting to load a difference version of xulrunner than what actually were present (it tried fstat-ing a non-existant directory).

Checking out the current configuration of gre in /etc/gre.d (.. where I’ve never ventured before) indicated that DPKG had left the new package configuration without switching it to the standard configuration. This meant that the old GRE configuration was used, and not the new one. Renaming the old configuration file to gibberish and then removing the suffix from the new one solved the issue.

  • Removed: 1.9.1.14.system.conf
  • Renamed: 1.9.2.11.system.conf.dpkg-bak to 1.9.2.11.system.conf

.. and now gnome-web-photo actually works again!

gnome-web-photo and GConf Error: Failed to contact configuration server

This error was quite hard to track down, and was also the cause for gnome-web-photo timing out. Things worked when running from the shell, but when running it through our web service (as another user), gnome-web-photo went misbehaving!

Reports on the intarwebs suggested changing ownership of the .dbus directory (so dbus can work properly), but as we don’t have a regular home directory for the user (we actually have to set a fake one to fool mozilla when it’s creating its .mozilla directory) we didn’t have any .dbus directories.

After toying around and getting nowhere fast, I finally had a bit of luck with just running dbus-launch before gnome-web-photo. This worked once, then things went back to being crap. After reading through the dbus-launch man page I finally found out that you can make dbus-launch set up the environment for proper dbus access and then launch a command line you provide.

End solution:

dbus-launch /usr/bin/gnome-web-photo -t 30 --mode=photo --format png ..

apc_mmap: mmap failed: Cannot allocate memory

While trying to increase the size of the APC segment on my development machine I suddenly started getting “apc_mmap: mmap failed: Cannot allocate memory” in my error_log. This also made Apache angry, so it refused to return any pages while the error message was present.

After removing the apc.shm_size again, things went back to working as normal.

A bit of psychic debugging and reading phpinfo() output revealed the culprit:

Do NOT include a “M” specifier when providing a size for apc.shm_size. Leave it off. It will assume MBs anyways. This solved the issue.

This is in contrast with the manual page, where it has been documented with a default value of “32M”, while phpinfo() says “32”. This behaviour change with APC 3.1.4, so if your version is older than that you’ll have to use the format without the M.