At startup, sogod says in its log file:

2011-02-24 20:46:18.748 sogod[6981] File NSData.m: 178.
In readContentsOfFile Seek to end of file (/net/bundle-info.plist)
failed - Invalid argument
2011-02-24 20:46:18.748 sogod[6981] could not load bundle-info at path
'/net/bundle-info.plist' !

This is repeated for /u/bundle-info.plist (/u is a symlink to /net), and
the pair is repeated 4 times, and it finishes up with the fatal error:

2011-02-24 20:46:18.789 sogod[6981] could not open channel to sogo@localhost
Feb 24 20:46:18 sogod [6981]: [ERROR] <0x0x8385eb0[GCSChannelManager]> could
not open channel <0x0x8314c30[PostgreSQL72Channel]: not-connected> for
URL: postgresql://sogo:password@localhost:5432/sogo/sogo_user_profile

I used strace to find out what sogod was doing. For most bundle objects
it found the plist file, e.g.
/usr/lib/GNUstep/SOGo/CommonUI.SOGo/bundle-info.plist, but in four cases
it lacked leading path components. There is no visible clue which bundle
object it was working on. It went through the root directory and statted
/*/bundle-info.plist, silently not finding it except in /net. So why is
it monkeying with the root directory?

/net is the root of an autofs filesystem, and it creates on the fly a
directory named after the host bundle-info.plist from which the user will
next request mounting of an exported filesystem, or so it thinks. The
EINVAL is the result of seeking to the end of the directory file. The
misbehavior only crashes sogod when the sought file appears on the fly,
but on a machine without autofs, strace reveals the same behavior (again
happening 4 times), but with no consequences because the file is never
bogusly found.