Kolab 3.4 on CentOS 6.6 (ptload completely failed)

[ellie timoney]

Hi Paul,

I have no insight into Andrea's original problem; I'm commenting
specifically on the /dev/shm thing.

> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//tls_sessions.db" in proc_foreach
> > [...]
> > The Point to look at is "/dev/shm//tls_sessions.db" which has one / too much it must be "/dev/shm/tls_sessions.db/". The same happens if you link the files/dir to /dev/shm.

This is a red herring.  Duplicated slashes in a path look ugly when
printed, but are treated as a single separator for all standard  file
operations.

In fact, rummaging in the code a bit, the extra "/" isn't even in the
path being examined -- it's being added by the syslog call that produces
the error message.

> >       # $confdir/proc/ will be used if not defined "proc_path"
> >       proc_path: /dev/shm
> >       # $confdir/lock will be used if not defined "mboxname_lockpath"
> >       mboxname_lockpath: /dev/shm
> >        # $confdir/statuscache.db will be used if not defined "statuscache_db_path"
> >       statuscache_db_path: /dev/shm/statuscache.db
> >        # $confdir/tls_sessions.db will be used if not defined "tls_sessions_db_path"
> >       tls_sessions_db_path: /dev/shm/tls_sessions.db
> >        # $confdir/deliver.db will be used if not defined "duplicate_db_path"
> >       duplicate_db_path: /dev/shm/deliver.db

Here's the problem.  

Cyrus (specifically: the proc_foreach function) expects the proc_path
directory to contain only proc files.  But this configuration is also
placing mbox name locks, the statuscache.db, the tls_sessions.db, and
the deliver.db in the same directory.  So proc_foreach is whinging about
these files, because they are not proc files.

I don't think this causes a problem per-se, except for the noise in the
log, but I'm not sure.

The way to fix this is to put the proc_path in its own directory, like
it expects.  Try:

proc_path: /dev/shm/proc

Similarly, mboxname_lockpath is usually its own directory (default:
$confdir/lock), so do the same thing there too:

mboxname_lockpath: /dev/shm/lock

Though for that matter, /dev/shm is used by the whole system.  It's
really not a great idea to just dump everything in there without further
namespacing (you wouldn't stick them in "/", would you?).  I would use
something like:

proc_path: /dev/shm/cyrus/proc
mboxname_lockpath: /dev/shm/cyrus/lock
statuscache_db_path: /dev/shm/cyrus/statuscache.db
tls_sessions_db_path: /dev/shm/cyrus/tls_sessions.db
duplicate_db_path: /dev/shm/cyrus/deliver.db

Please note that I present these configurations as examples of how one
should configure these items to live on /dev/shm, if one wanted to do
so.  I have, and offer, no opinion on whether doing so is a good idea or
not.

> > If you read in cyrus-imap docu there is recommended to point for performance reason some files to tmpfs files System like /dev/shm

This kind of sounds like it maybe said to use the /dev/shm file system
(implication: create the usual directory structure under there...) but
has been misinterpreted as saying to just literally stick this stuff
straight in /dev/shm.  But I don't know what documentation said to do
this.

Hope this helps,

ellie

On Sat, Sep 26, 2015, at 04:17 AM, signaldeveloper at gmail.com wrote:
> Guys,
> 
> Can you shed any light on the below? Andrea I copied in the Cyrus list
> guys. 
> 
> - Paul
> 
> > On Sep 25, 2015, at 11:28 AM, Soliva, Andrea <andrea.soliva at comcept.ch> wrote:
> > 
> > Hi Paul
> > 
> > here another issue I found...nothing to do with the issue. If you read in cyrus-imap docu there is recommended to point for performance reason some files to tmpfs files System like /dev/shm. This is specially also noted for cyrus-imapd v2.5. Actually the config would be:
> > 
> >       # vi /etc/impad.conf
> > 
> >       --------------- /etc/impad.conf ---------------
> > 
> >       configdirectory: /var/lib/imap
> >       # $confdir/proc/ will be used if not defined "proc_path"
> >       proc_path: /dev/shm
> >       # $confdir/lock will be used if not defined "mboxname_lockpath"
> >       mboxname_lockpath: /dev/shm
> >        # $confdir/statuscache.db will be used if not defined "statuscache_db_path"
> >       statuscache_db_path: /dev/shm/statuscache.db
> >        # $confdir/tls_sessions.db will be used if not defined "tls_sessions_db_path"
> >       tls_sessions_db_path: /dev/shm/tls_sessions.db
> >        # $confdir/deliver.db will be used if not defined "duplicate_db_path"
> >       duplicate_db_path: /dev/shm/deliver.db
> > 
> >       --------------- /etc/impad.conf ---------------
> > 
> > This does not work...which means because the Kolab guys patched the stuff from my Point of view there is a mistake in the code because if you use this config it works as Long as cyurs-imapd does not any maintenance or how every they call this because as soon as this happens you will have following error:
> > 
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: Deleted mailbox comcept.ch!user.andrea^soliva
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//tls_sessions.db" in proc_foreach
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//deliver.db" in proc_foreach
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//sem.slapd-kolab.stats" in proc_foreach
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//q" in proc_foreach
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//n" in proc_foreach
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//statuscache.db" in proc_foreach
> >        Aug 24 08:50:25 kolab imap/imaps[7782]: IOERROR: bogus filename "/dev/shm//domain" in proc_foreach
> > 
> > The Point to look at is "/dev/shm//tls_sessions.db" which has one / too much it must be "/dev/shm/tls_sessions.db/". The same happens if you link the files/dir to /dev/shm.
> > 
> > This only for your info :-)
> > 
> > ---
> > Kind regards
> > 
> > Andrea Soliva
> > 
> > Email: andrea.soliva at comcept.ch
> >