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@xxxxxxxxx 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@xxxxxxxxxx> 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@xxxxxxxxxx > > ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
