View Issue Details

IDProjectCategoryView StatusLast Update
0001153SOGoSOPEpublic2017-05-08 14:58
Reporterjimc_uclamath Assigned Toludovic  
Status closedResolutionunable to reproduce 
Product Version1.3.5 
Target VersionFixed in Version 
Summary0001153: Dies when it finds /net/bundle-info.plist
DescriptionAt 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.
Additional InformationSOGo version is 1.3.5a, and sope is v4.9.
TagsNo tags attached.




2011-03-03 19:25

administrator   ~0002188

This is likely a GNUstep issue more than a SOGo/SOPE issue.

Issue History

Date Modified Username Field Change
2011-02-25 01:23 jimc_uclamath New Issue
2011-03-03 10:23 ludovic Status new => assigned
2011-03-03 10:23 ludovic Assigned To => ludovic
2011-03-03 19:25 ludovic Note Added: 0002188
2012-11-18 11:26 ludovic Severity crash => minor
2017-05-08 14:58 ludovic Status assigned => closed
2017-05-08 14:58 ludovic Resolution open => unable to reproduce