Re: /opt/cyrus/mailboxes.db: Not enough space
On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: On Wed, 14 Jan 2004, Igor Brezac wrote: Hmm. You can clear this up by running db_recover from the /po/var/imap/db directory. What does db_stat -c say before you run db_recover? Do tls_prune|cyr_expire|ctl_cyrusdb -c run properly on your system? Also apply http://www.sleepycat.com/update/4.2.52/patch.4.2.52.html... Ah, thanks for pointing that out, and naughty me for not thinking to check for patches at the db site. Anyway... $ /usr/local/BerkeleyDB.4.2/bin/db_stat -c -h /po/var/imap/db 227362 Last allocated locker ID. 2147M Current maximum unused locker ID. 9 Number of lock modes. 5 Maximum number of locks possible. 5 Maximum number of lockers possible. 5 Maximum number of lock objects possible. 332 Number of current locks. 604 Maximum number of locks at any one time. 664 Number of current lockers. 1198Maximum number of lockers at any one time. 2 Number of current lock objects. 13 Maximum number of lock objects at any one time. 12M Total number of locks requested. 12M Total number of locks released. 0 Total number of lock requests failing because DB_LOCK_NOWAIT was set. 454 Total number of locks not immediately available due to conflicts. 0 Number of deadlocks. 0 Lock timeout value. 0 Number of locks that have timed out. 0 Transaction timeout value. 0 Number of transactions that have timed out. 19MB 624KB The size of the lock region.. 8560The number of region locks granted after waiting. 19M The number of region locks granted without waiting. How many clients did you have connected at that time? -- Igor
Re: /opt/cyrus/mailboxes.db: Not enough space
On Thu, 15 Jan 2004, Igor Brezac wrote: How many clients did you have connected at that time? At 01/13/04 23:30:00, looks like there were 465 cyrus processes. Looking a bit more closely lately, I notice a couple of these pop up: Jan 15 06:41:07 area51 imaps[4242]: Fatal error: tls_start_servertls() failed Jan 15 07:16:13 area51 imaps[5346]: Fatal error: tls_start_servertls() failed Jan 15 07:33:50 area51 imaps[7045]: Fatal error: tls_start_servertls() failed I wonder if that's some Eudora clients not liking our SSL. Though, it doesn't look like that caused a process to crash, so I don't know if that's related to DB issues. I applied that DB 4.2.52 patch and am now running with it, so we'll see if that makes any difference. -- Amos
Re: /opt/cyrus/mailboxes.db: Not enough space
Hmmm... I guess these issues are still present with DB-4.2.52: imaps[26503]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: cyrusdb error imaps[26828]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: Not enough space imaps[26828]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: cyrusdb error imaps[26832]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: Not enough space Someone back there in the early days of this thread mentioned the db_stat command: /usr/local/BerkeleyDB.4.2/bin/db_stat -e -h /po/var/imap/db 4.2.52 Environment version. 120897 Magic number. 0 Panic value. 968 References. 1911972 Locks granted without waiting. 28816 Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mpool Region: 2. 264KB Size. -1 Segment ID. 2353977 Locks granted without waiting. 190 Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Log Region: 3. 96KBSize. -1 Segment ID. 6430275 Locks granted without waiting. 14697 Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock Region: 4. 19MB 624KB Size. -1 Segment ID. 19M Locks granted without waiting. 8420Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Txn Region: 5. 32KBSize. -1 Segment ID. 2765561 Locks granted without waiting. 1152Locks granted after waiting. Is the only way to clear this up is to shutdown and blow away tls_sessions.db? I doubt it matters, but this is on: v2.2.2-BETA 2003/12/19 18:38:42 -- Amos
Re: /opt/cyrus/mailboxes.db: Not enough space
On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: Hmmm... I guess these issues are still present with DB-4.2.52: imaps[26503]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: cyrusdb error imaps[26828]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: Not enough space imaps[26828]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: cyrusdb error imaps[26832]: [ID 729713 local6.error] DBERROR: opening /po/var/imap/tls_sessions.db: Not enough space Someone back there in the early days of this thread mentioned the db_stat command: /usr/local/BerkeleyDB.4.2/bin/db_stat -e -h /po/var/imap/db 4.2.52 Environment version. 120897 Magic number. 0 Panic value. 968 References. 1911972 Locks granted without waiting. 28816 Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mpool Region: 2. 264KB Size. -1 Segment ID. 2353977 Locks granted without waiting. 190 Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Log Region: 3. 96KBSize. -1 Segment ID. 6430275 Locks granted without waiting. 14697 Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock Region: 4. 19MB 624KB Size. -1 Segment ID. 19M Locks granted without waiting. 8420Locks granted after waiting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Txn Region: 5. 32KBSize. -1 Segment ID. 2765561 Locks granted without waiting. 1152Locks granted after waiting. Is the only way to clear this up is to shutdown and blow away tls_sessions.db? I doubt it matters, but this is on: v2.2.2-BETA 2003/12/19 18:38:42 Hmm. You can clear this up by running db_recover from the /po/var/imap/db directory. What does db_stat -c say before you run db_recover? Do tls_prune|cyr_expire|ctl_cyrusdb -c run properly on your system? Also apply http://www.sleepycat.com/update/4.2.52/patch.4.2.52.html... -- Igor
Re: /opt/cyrus/mailboxes.db: Not enough space
On Wed, 14 Jan 2004, Igor Brezac wrote: Hmm. You can clear this up by running db_recover from the /po/var/imap/db directory. What does db_stat -c say before you run db_recover? Do tls_prune|cyr_expire|ctl_cyrusdb -c run properly on your system? Also apply http://www.sleepycat.com/update/4.2.52/patch.4.2.52.html... Ah, thanks for pointing that out, and naughty me for not thinking to check for patches at the db site. Anyway... $ /usr/local/BerkeleyDB.4.2/bin/db_stat -c -h /po/var/imap/db 227362 Last allocated locker ID. 2147M Current maximum unused locker ID. 9 Number of lock modes. 5 Maximum number of locks possible. 5 Maximum number of lockers possible. 5 Maximum number of lock objects possible. 332 Number of current locks. 604 Maximum number of locks at any one time. 664 Number of current lockers. 1198Maximum number of lockers at any one time. 2 Number of current lock objects. 13 Maximum number of lock objects at any one time. 12M Total number of locks requested. 12M Total number of locks released. 0 Total number of lock requests failing because DB_LOCK_NOWAIT was set. 454 Total number of locks not immediately available due to conflicts. 0 Number of deadlocks. 0 Lock timeout value. 0 Number of locks that have timed out. 0 Transaction timeout value. 0 Number of transactions that have timed out. 19MB 624KB The size of the lock region.. 8560The number of region locks granted after waiting. 19M The number of region locks granted without waiting. Though, things much quieter now than they were earlier. Hmmm... I wonder if I need to raise some of those limits. As to tls_prune|cyr_expire|ctl_cyrusdb, haven't seen any problems with those. I wonder if I should run tls_prune more often than the default once a day at 4am -- Amos
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: /opt/cyrus/mailboxes.db: Not enough space
Upgrade cyrus-imapd (it fixes an important bug with Berkeley DB 4.1.25) and use skiplist for mailboxes although you should be able to use berkeley as well. -Igor On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Igor
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, On Wed, 3 Dec 2003, Igor Brezac wrote: Upgrade cyrus-imapd (it fixes an important bug with Berkeley DB 4.1.25) and use skiplist for mailboxes although you should be able to use berkeley as well. Thanks for your advice. Is it actually this Not enough space problem which is addressed by the fix you mention above or is it just the db3 lockers problem about which I read the in the changelog (changes since 2.1.13: Correctly terminate the processes by calling service_abort even on successful exit (helps to fix a db3 lockers problem))? However, concerning skiplist I read about several issues in the recovery of a corrupted skiplist file. Are these issues fixes with 2.1.16? Or are you talking about updating the a 2.2 version? Thanks, Wolfgang -Igor On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, In short there seems to be some versions of the Berkeley DB that don't function well with Cyrus. I believe it is a bug within Berkeley DB, I suspect any application using it would have this problem. I don't know the differences between Berkeley DB and skiplist, but I do know that once I switched formats the problem went away and that was the most important thing from my standpoint. I'll leave the more DB specific technical descriptions/differences part to those who are more qualified. Jim At 02:19 PM 12/3/2003 +0100, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper Jim Howell CIT Messaging Systems Manager Cornell University 728 Rhodes Hall Email: [EMAIL PROTECTED] Phone: 607-255-9369
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, On Wed, 3 Dec 2003, Igor Brezac wrote: Upgrade cyrus-imapd (it fixes an important bug with Berkeley DB 4.1.25) and use skiplist for mailboxes although you should be able to use berkeley as well. Thanks for your advice. Is it actually this Not enough space problem which is addressed by the fix you mention above or is it just the db3 lockers problem about which I read the in the changelog (changes since 2.1.13: Correctly terminate the processes by calling service_abort even on successful exit (helps to fix a db3 lockers problem))? However, concerning skiplist I read about several issues in the recovery of a corrupted skiplist file. Are these issues fixes with 2.1.16? I don't have deep knowledge about skiplist. What I know is that it works great for the recommended dbs and recovery takes place whenever the skiplist file is accessed the first time after a server restart (at least it seems to me so). From what I know 2.2 is not really different with the db backends but what differs is the default and recommended backends for several dbs like mailboxes. They changed some of them to skiplist. Simon Or are you talking about updating the a 2.2 version? Thanks, Wolfgang -Igor On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1% /opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2% /opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1% /opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107
Re: /opt/cyrus/mailboxes.db: Not enough space
On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, On Wed, 3 Dec 2003, Igor Brezac wrote: Upgrade cyrus-imapd (it fixes an important bug with Berkeley DB 4.1.25) and use skiplist for mailboxes although you should be able to use berkeley as well. Thanks for your advice. Is it actually this Not enough space problem which is addressed by the fix you mention above or is it just the db3 lockers problem about which I read the in the changelog (changes since 2.1.13: Correctly terminate the processes by calling service_abort even on successful exit (helps to fix a db3 lockers problem))? This is the same problem: not 'releasing' lockers cause Berkeley environment to run out of space. However, concerning skiplist I read about several issues in the recovery of a corrupted skiplist file. Are these issues fixes with 2.1.16? Or are you talking about updating the a 2.2 version? I believe the skiplist code is the same in both versions. I've never experienced problems with skiplist and I run a farily big email server. -Igor Thanks, Wolfgang -Igor On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, Please define Fairly Big... I have systems with 10,000 users with no problems using skiplist. Jim At 10:59 AM 12/3/2003 -0500, Igor Brezac wrote: On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, On Wed, 3 Dec 2003, Igor Brezac wrote: Upgrade cyrus-imapd (it fixes an important bug with Berkeley DB 4.1.25) and use skiplist for mailboxes although you should be able to use berkeley as well. Thanks for your advice. Is it actually this Not enough space problem which is addressed by the fix you mention above or is it just the db3 lockers problem about which I read the in the changelog (changes since 2.1.13: Correctly terminate the processes by calling service_abort even on successful exit (helps to fix a db3 lockers problem))? This is the same problem: not 'releasing' lockers cause Berkeley environment to run out of space. However, concerning skiplist I read about several issues in the recovery of a corrupted skiplist file. Are these issues fixes with 2.1.16? Or are you talking about updating the a 2.2 version? I believe the skiplist code is the same in both versions. I've never experienced problems with skiplist and I run a farily big email server. -Igor Thanks, Wolfgang -Igor On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586
Re: /opt/cyrus/mailboxes.db: Not enough space
On Wed, 3 Dec 2003, Jim Howell wrote: Hi, Please define Fairly Big... I have systems with 10,000 users with no problems using skiplist. 15,000 mboxes... -Igor Jim At 10:59 AM 12/3/2003 -0500, Igor Brezac wrote: On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, On Wed, 3 Dec 2003, Igor Brezac wrote: Upgrade cyrus-imapd (it fixes an important bug with Berkeley DB 4.1.25) and use skiplist for mailboxes although you should be able to use berkeley as well. Thanks for your advice. Is it actually this Not enough space problem which is addressed by the fix you mention above or is it just the db3 lockers problem about which I read the in the changelog (changes since 2.1.13: Correctly terminate the processes by calling service_abort even on successful exit (helps to fix a db3 lockers problem))? This is the same problem: not 'releasing' lockers cause Berkeley environment to run out of space. However, concerning skiplist I read about several issues in the recovery of a corrupted skiplist file. Are these issues fixes with 2.1.16? Or are you talking about updating the a 2.2 version? I believe the skiplist code is the same in both versions. I've never experienced problems with skiplist and I run a farily big email server. -Igor Thanks, Wolfgang -Igor On Wed, 3 Dec 2003, Wolfgang Hottgenroth wrote: Hi, unfortunately I read this message not earlier than today ... when I ran into a similar situation with the 'DBERROR: ... Not enough space'. I'm using cyrus-imap-2.1.12 with Berkeley DB 4.1.25. So, I understand correct, that you recommend against using the default setting (Berkeley DB) for the mailboxes list but skiplist? What actually means 'skiplist'? And what is the difference to 'flat'? And, does it actually means that Berkeley DB won't work properly together with cyrus imap? Thanks, Wolfgang On Fri, 28 Mar 2003, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue
/opt/cyrus/mailboxes.db: Not enough space
Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim
Re: /opt/cyrus/mailboxes.db: Not enough space
If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: /opt/cyrus/mailboxes.db: Not enough space
Either use the cvt_cyrusdb program or dump and undump (with a newly-compiled version of cyrus) your mailbox list (using ctl_mboxlist) -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, No I guess I hadn't heard that suggestion before. Thanks.. Is there an easy way to go from BerkeleyDB to skiplist? Jim At 11:26 AM 3/28/2003 -0500, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, No I guess I hadn't heard that suggestion before. Thanks.. Is there an easy way to go from BerkeleyDB to skiplist? Jim At 11:26 AM 3/28/2003 -0500, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: /opt/cyrus/mailboxes.db: Not enough space
Hi, I was thinking the second method would work however I like the first one as well. Thanks. Jim At 02:29 PM 3/28/2003 -0500, Rob Siemborski wrote: Either use the cvt_cyrusdb program or dump and undump (with a newly-compiled version of cyrus) your mailbox list (using ctl_mboxlist) -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, No I guess I hadn't heard that suggestion before. Thanks.. Is there an easy way to go from BerkeleyDB to skiplist? Jim At 11:26 AM 3/28/2003 -0500, Rob Siemborski wrote: If you haven't had the suggestion before, it's really not recommended to use Berkeley DB for your mailbox list. Use skiplist instead. -Rob On Fri, 28 Mar 2003, Jim Howell wrote: Hi, Last night we had this happen again on one of our systems. What is the current thinking as to the cause and/or fix to this problem? I saw one response last time that said backing off to DB 4.0 would help. Again the versions of things are: Sendmail 8.12.8 Cyrus 2.1.11 Berkeley DB 4.1.24 Thanks. Jim Hi, I have an interesting problem. Over the weekend our syslog forwarder went beserk generating over 300,000 messages to about 6 people. This morning our three new Cyrus systems went belly up, (yes that is a technical term), actually the master daemon seemed to eventually freeze up. The only real error msgs I can find are these: Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: opening /opt/cyrus/mailboxes.db: Not enough space Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 messages a day with no trouble. I don't believe space is really an issue, here is a df -k from one of the systems. Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 1984564 904568 102046047%/ /proc 0 0 0 0%/proc fd 0 0 0 0%/dev/fd mnttab 0 0 0 0%/etc/mnttab /dev/md/dsk/d1962573 255248 64957129%/var swap 28642528 32 28642496 1%/var/run swap 28655440 12944 28642496 1%/tmp /dev/md/dsk/d4 50408148134 4982272 1%/users /dev/md/dsk/d3 5040814 452439 453796710%/opt /dev/vx/dsk/po8_dg01/logvol01 5160542 115891 4993046 3%/logs /dev/vx/dsk/po8_dg01/mqueuevol01 103218844986 10213680 1%/mqueue /dev/vx/dsk/po8_dg01/cyrus_data_vol01 41287586 126222 40748489 1%/opt/cyrus /dev/vx/dsk/po8_dg01/sendmailvol01 41287586 603402 40271309 2%/opt/sendmail_vol /dev/vx/dsk/po8_dg01/cyrus_app_vol01 41287586 147526 40727185 1%/opt/cyrus_vol /dev/vx/dsk/po8_dg01/spoolvol01 103218991 679107 101507695 1%/var/spool/mail swap 28642640 144 28642496 1%/opt/cyrus/proc /dev/vx/dsk/po8_dg01/appvol01 20643785 54397 20382951 1%/applications This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 and, Sendmail 8.12.8. Anyone seen this before? Thanks. Jim -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
