You miss the point. The problems reported by fsck is the effect of problems caused by dbmail
I can resolve them by restarting dbmail -imap daemon and there will be no need to run fsck because by restarting dbmail i solve unref files Now i'm testing the patch provided by Paul. This could take a few days to see if it works. I see that in config by default MAXCONNECTS = 10000 what is the benefit to have it so hight? what would happen if i change it to Paul's suggested 100? Curtis Maurand wrote: > > Change your tmp environment variable to point somewhere else, then > restart whichever daemons need to be restarted so that their tmp paths > are changed. then umount the folder and fsck it. then remount it and > reverse your tmp environment variable changes and restart/reload your > daemons again. > > Cheers, > > > Paul J Stevens wrote: >> Guntis, >> >> try the attached patch if you will. >> >> But more importantly. a reliable workaround that won't require testing >> patches is to tune down the MAXCONNECTS parameter to 100 or so. This >> will prevent forked children from running too long. >> >> 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 >>> >>> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> DBmail mailing list >> [email protected] >> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > > ------------------------------------------------------------------------ > > _______________________________________________ > DBmail mailing list > [email protected] > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
