You are here: Foswiki>Tasks Web>Item15020 (09 Mar 2021, ColasNahaboo)Edit Attach

Item15020: Upgrading the server from 32bit to 64bit breaks Foswiki

Priority: Low
Current State: Confirmed
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: Session
Reported By: ColasNahaboo
Waiting For:
Last Change By: ColasNahaboo
I upgraded the server running a Foswiki instance from a 32bit Debian to a 64bit one, same version.

All the pages of the Foswiki became unavailable with the error:

Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.

Long integer size is not compatible

This is becauses Foswiki stores some Session info in the cookie itself, but in a way that is dependent on the server architecture. Reading on a 64bit server a cookie made on a 32bit server fails. And I have not checked, but it may be also the case with changes in the big/little endian, etc...

It fails in CGI::Session::Serialize::storable::thaw from Foswiki::LoginManager::Session::load

Suggested remediation: make cookie storage encoding hardware-independant. And in the meantime, document it in the FAQ.

Workaround: Delete all cookies for the server in all the clients. I could not find a way to invalidate all the cookies from the server itself.

Severity: It should not happen frequently, but it is quite puzzling when it does. Logs do not give any indication, I had to add stack traces in the perl distributed modules to find the problem.

-- ColasNahaboo - 07 Mar 2021

Instead of making cookie storage hardware-independent I'd rather suggest to leverage the store API of CGI::Session to Foswiki to be able to plugin different ones, e.g. SQL, instead of Storable. This would help in other situations as well, say clustering multiple Foswiki engines, all of them reading session information from a central cookie store instead of having their own one locally each.

This would not directly have prevented you from having problems migrating to 64bit, but it does so in a more broader sense.

You actuall shipwreck is actually to be expected. Frankly, this is rather a mild one wink E.g. local perl packages need recompilation if they have XS parts, perlmagick for sure; a couple of plugins create caches using Storable or Sereal. These caches all need to be nuked before being able to restart on 64 pots.

-- MichaelDaum - 08 Mar 2021

Actually, I never use CPAN, and only rely on Debian perl packages, so the local perl packages were not an issue. (I re-installed on a fresh 64bit install) And I expected this problem, so I deleted working/work_areas/ anyways.

But I wasn't expecting non-portable data in the cookie itself. Again, I do not think it warrant a fix in the implementation, just a mention in the FAQ.

-- ColasNahaboo - 09 Mar 2021

ItemTemplate edit

Summary Upgrading the server from 32bit to 64bit breaks Foswiki
ReportedBy ColasNahaboo
Codebase 2.1.6
SVN Range
AppliesTo Engine
Component Session
Priority Low
CurrentState Confirmed
TargetRelease n/a
ReleasedIn n/a
Topic revision: r3 - 09 Mar 2021, ColasNahaboo
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy