Guntis Bumburs wrote: > Anatoly wrote: > >> Guntis Bumburs wrote: >> >> >>> Hello, >>> >>> I have a problem with dbmail on Freebsd. The situation is that dbmail >>> fills all the /tmp space (seems to not releasing used space/opened file) >>> and when it's full the imap daemon starts acting strange, postfix cant >>> flush new mails ... (pop daemon still works). >>> We have 2 installations with identical symptoms. >>> >>> 1. Our setup >>> FreeBSD 7.0-RELEASE-p7 >>> dbmail 2.2.11 >>> Mysql 5.0 hosted on dedicated server >>> >>> The problem happen rarely (once in a few month) could be because the low >>> traffic volume. >>> >>> #du -h /tmp >>> shows 88K used >>> >>> #df -h /tmp >>> shows 89M used >>> >>> # lsof | grep /tmp | grep dbmail >>> shows lots of open files .. >>> >>> ..... >>> dbmail-im 97091 nobody 18u VREG 0,92 82761 269 /tmp >>> (/dev/da0s1e) >>> dbmail-im 97091 nobody 19u VREG 0,92 82761 274 /tmp >>> (/dev/da0s1e) >>> dbmail-im 97091 nobody 20u VREG 0,92 1176746 275 /tmp >>> (/dev/da0s1e) >>> dbmail-im 97091 nobody 21u VREG 0,92 57917 279 /tmp >>> (/dev/da0s1e) >>> ..... >>> >>> summing the sizes seems to cerate these 89M >>> >>> >>> case Nr 2 is an installation for our client >>> FreeBSD 6.2-RELEASE-p11 >>> dbmail 2.2.11 >>> Mysql also hosted on other server >>> >>> It takes ~ 1 week to fill the /tmp >>> >>> #du -h /tmp shows 734K >>> # df -h /tmp shows 278M >>> #lsof | grep /tmp | grep dbmail >>> shows lots of open files >>> ..... >>> dbmail-im 97519 nobody 17u VREG 0,89 12840447 69 /tmp >>> (/dev/ad0s1e) >>> dbmail-im 97519 nobody 18u VREG 0,89 9689295 72 /tmp >>> (/dev/ad0s1e) >>> dbmail-im 97519 nobody 19u VREG 0,89 327779 78 /tmp >>> (/dev/ad0s1e) >>> dbmail-im 97519 nobody 20u VREG 0,89 447281 81 /tmp >>> (/dev/ad0s1e) >>> .... >>> >>> The probleam was also for dbmail 2.2.10 and some earlier versions >>> For now we have to periodically restart dbmail-imap daemon to release >>> /tmp. Also i have noticed that if i restart mysql (witch is on different >>> server) >>> /tmp is also freed. >>> >>> How can i be useful to help solve this problem? >>> >>> >>> Best Regards, >>> Guntis >>> >>> _______________________________________________ >>> DBmail mailing list >>> [email protected] >>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail >>> >>> >>> >>> >> fsck /tmp >> >> > smtp-mx1# fsck /tmp > ** /dev/da0s1e (NO WRITE) > ** Last Mounted on /tmp > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > UNREF FILE I=4 OWNER=nobody MODE=100600 > SIZE=1356 MTIME=Apr 23 07:12 2009 > CLEAR? no > > UNREF FILE I=13 OWNER=nobody MODE=100600 > SIZE=2586321 MTIME=Apr 23 08:41 2009 > CLEAR? no > > UNREF FILE I=14 OWNER=nobody MODE=100600 > SIZE=3874 MTIME=Apr 23 03:03 2009 > CLEAR? no > ..... > ..... > ** Phase 5 - Check Cyl groups > 104 files, 27824 used, 225991 free (199 frags, 28224 blocks, 0.1% > fragmentation) > > That is not a solution. I will have to umount /tmp (i can do it by force > or stop daemons witch is using /tmp and do normal umount). By stoping > dbmail-imap the problem is resolved. > So the problems reported by fsck is the effect of problems caused by dbmail. > > > _______________________________________________ > DBmail mailing list > [email protected] > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > df statistics on my client host: http://munin.rixtel.com/studio7pro.lv/mx1.studio7pro.lv-df.html note: on April 17th i have restarted dbmail-imap daemon that's why the /tmp flushed also we can note that sometimes there is some releases
Our company box: http://munin.rixtel.com/rixtel.com/smtp-mx1.rixtel.com-df.html there we can see that tmp is usually released and not growing so quickly like on the client server. This could be because we have less traffic. _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
