General discussion on installation and configuration of SOGo

Text archives Help

[SOGo] Crash with

Chronological Thread 
  • From: NSS Ltd < >
  • To:
  • Subject: [SOGo] Crash with
  • Date: Sun, 29 Jun 2014 19:20:35 +0100

I am seeing a crash with SOGo configured with an SQL user source - in
this case, a PostgreSQL view built against an Archiveopteryx IMAP server
(so there is a unified logon).

There was an old question asked a couple of years ago (!) with very
similar problems (January 2011 - but with
no clear fix.

I tried making a plain table instead of the view but that did not make
any difference - still crashes.

The log shows this (for a free/busy lookup for an example user 'nancy'
which I know is there and has appointments etc.) . It seems to be the
lookup/autocomplete which is problematic in the free/busy:

2014-06-29 14:10:43.870 sogod[21213] PostgreSQL72 connection
established: <0x0x7fe32e0cb638[PGConnection]: connection=0x0x7fe32e0f37d0>
2014-06-29 14:10:43.870 sogod[21213] PostgreSQL72 channel
0x0x7fe32e0afb48 opened (connection=<0x0x7fe32e0cb638[PGConnection]:
2014-06-29 14:10:43.870 sogod[21213] PG0x0x7fe32e0afb48 SQL: SELECT *
FROM sogo_users WHERE (LOWER(c_cn) LIKE '%nancy%' OR LOWER(mail) LIKE
EXCEPTION: <NSException: 0x7fe32e14bce8> NAME:NSInvalidArgumentException
REASON:Number of objects does not match the number of keys. INFO:(null)
Jun 29 14:10:44 sogod [15697]: <0x0x7fe32dd50d78[WOWatchDogChild]> child
21213 exited
Jun 29 14:10:44 sogod [15697]: <0x0x7fe32dd50d78[WOWatchDogChild]>
(terminated due to signal 6, coredump)

The view statement (if that's relevant, perhaps due to columns available
?) :

create view sogo_users as select login as c_uid, login as c_id,
md5(secret) as c_password, name as c_cn, name as displayName, localpart
|| '@' || domain as mail FROM users join aliases using (id) join
addresses c on (;

As an aside, it was necessary to add the MD5 as the sogo.conf would not
validate if I had plain-text used as the method. As soon as I made it
MD5, it worked as soon as I changed the hash method to MD5 to match. As
plain-text it was a no-go.

Database server is PostgreSQL 9.2 - nothing is logged in the log files
for that and the query run manually works correctly (returns 1 row as
expected), so database permissions all look OK. If these were wrong,
the login would fail (tested by changing the permissions to make it fail
then return them so it works).

And ideas or suggestions would be appreciated.


  • [SOGo] Crash with, NSS Ltd, 06/29/2014

Archive powered by MHonArc 2.6.18.

Top of page