Plone 4.1->4.2 Upgrade Exits with Error 247

Plone Support
1

Hi,

in an attempt to upgrade a Plone 4.1 site to Plone 4.2, Plone stops with an exit code 247, but without any error message whatsoever.

It turned out that the VM had not enough RAM. The upgrade ran fine with 2G of memory.

3

Toni Müller via Plone Community wrote at 2024-9-17 22:46 +0000:

in an attempt to upgrade a Plone 4.1 site to Plone 4.2, Plone stops with an exit code 247, but without any error message whatsoever.

This is a strange exit code for *nix systems. On *nix systems,
it would usually mean that
the process was terminated by the signal 119 (= 247-128)
but there is no such signal.

What OS are you using?

I run Plone like this:

$ ./bin/secondary fg

When I press the Upgrade button in the PMI, I see a flurry of messages, but before Plone exits, there are these error messages:

ERROR GenericSetup Step pleonformgen has an invalid import handler
ERROR GenericSetup Step seo_uninstall has an invalid import handler

and

WARNING GenericSetup There are unresolved or circular dependencies. Graphviz diagram::   ...

mentioning several products which are not installed, but were, earlier, then

INFO GenericSetup.rolemap Role / permission map imported.
WARNING GenericSetup.toolset Not creating required tool formgen_tool, because class Products.PloneFormGen.tools.formGenTool.FormGenTool is not found.
INFO GenericSetup.toolset Toolset imported.
$ echo $?
247

GenericSetup is very sensible regarding removal of previously
installed packages:
it stores information about previous imported import steps
in the ZODB and this information becomes invalid when the mentioned
packages are removed.

Usually, those situations result in log entries (like those
you have observed) but are not fatal, i.e. they should not
explain the process termination.

In general, you should ensure that a migration target
installation has the same packages as the source.

Can anyone please point me into the right direction for a good debugging strategy?

Because of the strange exit code, I have problems
to give advice regarding the problem.

247 == -9 & 0xff. Thus, if on your system a process
termination by signal N leads to an exit code -N & 0xff,
then this would mean that the process was terminated
by signal 9 (SIGKILL ?).

If I would be confronted personally, I would likely use
C level debugging to find out what caused the process termination:
either

  • configure your system that core dumps are written
    and examine the core with a C level debugger
    or
  • attach gdb (the GNU DeBugger) to the process and let
    it report how and where the process got terminated
    But this requires a lot of special knowledge about C level
    debugging and the underlying operating system.
4

Hi Dieter,
thank you for the response. I had gone through all the steps of deinstalling the packages from the PMI and then running buildout, server restarts and everything, but these error messages were still there, as well as a few others, the most obnoxious being some portlets and portletmanagers that I wanted to get rid of. I ended up ignoring those and just choosing a different view that should not use them to get anywhere.

I happened to come across that error message via StackOverflow, where someone with a Django site ran into a similar problem. Increasing the memory did fix it for them, and it was a cheap thing to try. Increasing the memory size fixed the problem for me as well, so I didn't bother to dig further.

The error message is supposed to be something like "socket already in use", but in the SO post, they said it was a memory problem.

I'm running just standard Debian VMs.

Btw, someone might want to add a hint to the docs for collective.exportimport that this software wants to hold all contents it wants to export in memory. It appears that it requires roughly 10x as much memory as the resulting JSON will be. This might not work well for larger amounts of content.