Hello Enrique, 1) Please try pam_mysql-0.7-pre1-1.i386.rpm (I've compiled it foe SLES 9, but should also work on SuSE 9.3) and post here if the problem still exists.
2) If that won't help, try solution from http://www.livejournal.com/users/realgreendragon/ (of Howard Shere) Quote: "The biggest optimization I found was to allow saslauthd to cache stuff so it didn't have to do a mysql query each time someone checked their mail. We now use the following flags when starting saslauthd: FLAGS='-n0 -s 2048 -t 3600 -c' The -n0 forces sasl to fork every time it invokes pam. This is important because there seems to be a memory leak somewhere in pam and if you don't do this your machine will run out of memory. My own server was having this problem every few months, but the load on my server is light. The load on the new server was making the memory run out in less than day. The other options cause sasl to cache stuff and that has been significant in terms of performance. The other thing about sasl is that there is an oddness to how it is started. Part of the problem we ran into was after rebooting the machine after putting new RAM in. Authentication was working sometimes before the reboot and we were pretty sure it was load related and possibly lack of memory related. So we put RAM in and rebooted and then no authentication was working. It turns out that sasl is startd two different ways. One way (which I am pretty sure is what happens on startup) is: /etc/init.d/saslauthd start That is normal and in the above file is a place for the sasl FLAGS as well as the authentication mechanism (MECH) that should be used. But it turns out that while the system is running, something else launches saslauthd as well and it gets its params from: /etc/sysconfig/saslauthd That file also has a place for FLAGS and for MECH. On our system they didn't match. So some of the saslauthd invokations were incorrect and would not authenticate people. After the reboot none of them were correct. So make sure you change these settings in both of these places (or I suppose you could dig and try to figure out why this is happening, but once we got things working we didn't want to mess with them anymore)." Regards, Leon Kolchinsky -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 19, 2005 9:21 PM To: [email protected] Subject: Re: [Web-cyradm] saslauthd memory leak? Zitat von Dirk Enrique Seiffert <[EMAIL PROTECTED]>: > I am running web-cyradm with MailScanner on SuSE 9.3, patched custom > kernel > 2.6.11.4 on a Dual Xeon Mailserver with 2G Ram. The server processes > an average of 20.000 mails per day for about 200 users. After a few > days of uptime the machine starts swapping until it crashes with an > OoM-Killer after about 10-15 days. As this doesn't happen frequently > it ends up very difficult to track down the problem. Now I noticed > that saslauthd starts to comsume lots of memory after beeing up for a while. > > On the list archives I saw some posts reporting this problem 2years > ago. I use cyrus-sasl-saslauthd-2.1.20 - Does anybody know this > problem or -even better- a solution? Restarting daily by cron could be > a workaround? As fas as i know it isn't saslauthd but pam_mysql which leaks memory. We have "solved" it by using saslauthd with "-n 0" option but i don't know if this is recommended for a high traffic site. Which pam_mysql version are you using? I have not tested the 0.6.x version until now. BTW : Why do you use a patched kernel instead of the stock SuSE 9.3 (just curious) Regards Andreas _______________________________________________ This mailing list is hosted and supported by bit-heads GmbH | http://www.bit-heads.ch _______________________________________________ Web-cyradm mailing list [email protected] http://www.web-cyradm.org/mailman/listinfo/web-cyradm
pam_mysql-0.7-pre1-1.i386.rpm
Description: pam_mysql-0.7-pre1-1.i386.rpm
_______________________________________________ This mailing list is hosted and supported by bit-heads GmbH | http://www.bit-heads.ch _______________________________________________ Web-cyradm mailing list [email protected] http://www.web-cyradm.org/mailman/listinfo/web-cyradm
