Re: [vchkpw] authdaemond Memory Leak?
Rick Widmer wrote: The only thing that says memory leak is in 5.4.18. There are many bug fixes, and a few new features in 5.4.25, the current stable version. If you are using vpopmaild you would want 5.4.26 the current dev release. If you are on solaris, there is a fix that is only in 5.4.27 which is only available from CVS. I would not suggest 5.4.25, 5.4.23 is the last version which seems to be stable. *.25 has a mail quota bug confirmed by a number of us, I went back to *.23 and no longer have the issue, by way of confirmation. !DSPAM:4750217032002890015292!
Re: [vchkpw] authdaemond Memory Leak?
Matthew Goodman wrote: Thanks, I am using Vpopmail 5.4.18. Was the fix after that release? The only thing that says memory leak is in 5.4.18. There are many bug fixes, and a few new features in 5.4.25, the current stable version. If you are using vpopmaild you would want 5.4.26 the current dev release. If you are on solaris, there is a fix that is only in 5.4.27 which is only available from CVS. I wish I could say upgrading will fix the problem, but vpopmail was never designed to run as a daemon. I'm not sure there is an easy fix other than more careful design on version 6. I'm afraid I don't have a lot of time for vpopmail right now, but if someone can come up with a patch, I'll gladly add it and put out a new release. (Patches against .25, .26 or CVS only, please.) Rick !DSPAM:474ffd8532003114249941!
Re: [vchkpw] authdaemond Memory Leak?
There was a memory problem in an old version of vpopmail library. It was related to usage of vlimits in MySQL. Check within mailing list for such information. You have to ugrade/fix, then recompile vpomail and courier-authdaemon. Ciao, Tonino Matthew Goodman ha scritto: Hello, I've noticed that courier-authlib slowly uses up memory over time on my Gentoo linux server. Using 2.6.21-gentoo-r4 kernel, compiler GCC 4.1.2, glibc 2.5-r4. Using the authvchkpw library, authdaemond usage looks like this after about a week: top - 00:42:49 up 22 days, 20:31, 2 users, load average: 2.08, 2.52, 2.54 Tasks: 271 total, 2 running, 269 sleeping, 0 stopped, 0 zombie Mem: 2074712k total, 1966420k used, 108292k free, 134520k buffers Swap: 1951800k total, 1113692k used, 838108k free, 547588k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7885 root 15 0 217m 68m 932 S0 3.4 0:40.84 /usr/lib/courier/courier-authlib/authdaemond 7884 root 15 0 216m 66m 928 S0 3.3 0:39.71 /usr/lib/courier/courier-authlib/authdaemond 7883 root 15 0 208m 66m 928 S0 3.3 0:38.41 /usr/lib/courier/courier-authlib/authdaemond 7886 root 15 0 217m 65m 928 S0 3.2 0:40.57 /usr/lib/courier/courier-authlib/authdaemond 7882 root 15 0 212m 65m 932 S0 3.2 0:38.97 /usr/lib/courier/courier-authlib/authdaemond Once I restart the service, usage looks much better: root 14565 0.0 0.0 4644 1132 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14569 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14570 0.0 0.0 4644 424 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14571 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14572 0.0 0.0 4812 1436 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14573 0.0 0.0 4812 1476 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond From /etc/courier/authlib/authdaemonrc: --- authmodulelist=authvchkpw daemons=5 DEFAULTOPTIONS= LOGGEROPTS= There is another post on the courier-users mailing list about this, user is also using a Gentoo environment and he was told to post on the vchkpw mailing list. Link included for reference: http://readlist.com/lists/lists.sourceforge.net/courier-users/0/3901.html Any input would be greatly appreciated. Matt -- [EMAIL PROTECTED]Interazioni di Antonio Nati http://www.interazioni.it [EMAIL PROTECTED] !DSPAM:474feded32001983814615!
RE: [vchkpw] authdaemond Memory Leak?
Thanks, I am using Vpopmail 5.4.18. Was the fix after that release? Matt From: tonix (Antonio Nati) [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 1:03 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] authdaemond Memory Leak? There was a memory problem in an old version of vpopmail library. It was related to usage of vlimits in MySQL. Check within mailing list for such information. You have to ugrade/fix, then recompile vpomail and courier-authdaemon. Ciao, Tonino Matthew Goodman ha scritto: Hello, I've noticed that courier-authlib slowly uses up memory over time on my Gentoo linux server. Using 2.6.21-gentoo-r4 kernel, compiler GCC 4.1.2, glibc 2.5-r4. Using the authvchkpw library, authdaemond usage looks like this after about a week: top - 00:42:49 up 22 days, 20:31, 2 users, load average: 2.08, 2.52, 2.54 Tasks: 271 total, 2 running, 269 sleeping, 0 stopped, 0 zombie Mem: 2074712k total, 1966420k used, 108292k free, 134520k buffers Swap: 1951800k total, 1113692k used, 838108k free, 547588k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7885 root 15 0 217m 68m 932 S0 3.4 0:40.84 /usr/lib/courier/courier-authlib/authdaemond 7884 root 15 0 216m 66m 928 S0 3.3 0:39.71 /usr/lib/courier/courier-authlib/authdaemond 7883 root 15 0 208m 66m 928 S0 3.3 0:38.41 /usr/lib/courier/courier-authlib/authdaemond 7886 root 15 0 217m 65m 928 S0 3.2 0:40.57 /usr/lib/courier/courier-authlib/authdaemond 7882 root 15 0 212m 65m 932 S0 3.2 0:38.97 /usr/lib/courier/courier-authlib/authdaemond Once I restart the service, usage looks much better: root 14565 0.0 0.0 4644 1132 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14569 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14570 0.0 0.0 4644 424 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14571 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14572 0.0 0.0 4812 1436 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14573 0.0 0.0 4812 1476 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond From /etc/courier/authlib/authdaemonrc: --- authmodulelist=authvchkpw daemons=5 DEFAULTOPTIONS= LOGGEROPTS= There is another post on the courier-users mailing list about this, user is also using a Gentoo environment and he was told to post on the vchkpw mailing list. Link included for reference: http://readlist.com/lists/lists.sourceforge.net/courier-users/0/3901.html Any input would be greatly appreciated. Matt -- [EMAIL PROTECTED]Interazioni di Antonio Nati http://www.interazioni.it [EMAIL PROTECTED] !DSPAM:474ff30032002235560276!
Re: [vchkpw] authdaemond Memory Leak?
5.4.18 should be fine. Did you rebuild courier-authdaemon after installing 5.4.18? See more on http://www.mail-archive.com/vchkpw@inter7.com/msg24203.html Ciao, Tonino Matthew Goodman ha scritto: Thanks, I am using Vpopmail 5.4.18. Was the fix after that release? Matt *From:* tonix (Antonio Nati) [mailto:[EMAIL PROTECTED] *Sent:* Friday, November 30, 2007 1:03 AM *To:* vchkpw@inter7.com *Subject:* Re: [vchkpw] authdaemond Memory Leak? There was a memory problem in an old version of vpopmail library. It was related to usage of vlimits in MySQL. Check within mailing list for such information. You have to ugrade/fix, then recompile vpomail and courier-authdaemon. Ciao, Tonino Matthew Goodman ha scritto: Hello, I've noticed that courier-authlib slowly uses up memory over time on my Gentoo linux server. Using 2.6.21-gentoo-r4 kernel, compiler GCC 4.1.2, glibc 2.5-r4. Using the authvchkpw library, authdaemond usage looks like this after about a week: top - 00:42:49 up 22 days, 20:31, 2 users, load average: 2.08, 2.52, 2.54 Tasks: 271 total, 2 running, 269 sleeping, 0 stopped, 0 zombie Mem: 2074712k total, 1966420k used, 108292k free, 134520k buffers Swap: 1951800k total, 1113692k used, 838108k free, 547588k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7885 root 15 0 217m 68m 932 S0 3.4 0:40.84 /usr/lib/courier/courier-authlib/authdaemond 7884 root 15 0 216m 66m 928 S0 3.3 0:39.71 /usr/lib/courier/courier-authlib/authdaemond 7883 root 15 0 208m 66m 928 S0 3.3 0:38.41 /usr/lib/courier/courier-authlib/authdaemond 7886 root 15 0 217m 65m 928 S0 3.2 0:40.57 /usr/lib/courier/courier-authlib/authdaemond 7882 root 15 0 212m 65m 932 S0 3.2 0:38.97 /usr/lib/courier/courier-authlib/authdaemond Once I restart the service, usage looks much better: root 14565 0.0 0.0 4644 1132 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14569 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14570 0.0 0.0 4644 424 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14571 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14572 0.0 0.0 4812 1436 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14573 0.0 0.0 4812 1476 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond From /etc/courier/authlib/authdaemonrc: --- authmodulelist=authvchkpw daemons=5 DEFAULTOPTIONS= LOGGEROPTS= There is another post on the courier-users mailing list about this, user is also using a Gentoo environment and he was told to post on the vchkpw mailing list. Link included for reference: http://readlist.com/lists/lists.sourceforge.net/courier-users/0/3901.html Any input would be greatly appreciated. Matt -- [EMAIL PROTECTED]Interazioni di Antonio Nati http://www.interazioni.it [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- [EMAIL PROTECTED]Interazioni di Antonio Nati http://www.interazioni.it [EMAIL PROTECTED] !DSPAM:474ffd1832009299229059!
Re: [vchkpw] authdaemond Memory Leak?
Same issue on Gentoo with vpopmail-5.4.16. I searched a few months ago and have been scanning the mail lists since then with no mention of a bug fix specific to this. For now I just monitor and use # /etc/init.d/courier-authlib restart every so often. My mail server is not so busy so I can afford to do this. A cron job to restart would be easy to implement. Pat Matthew Goodman wrote: Hello, I've noticed that courier-authlib slowly uses up memory over time on my Gentoo linux server. Using 2.6.21-gentoo-r4 kernel, compiler GCC 4.1.2, glibc 2.5-r4. Using the authvchkpw library, authdaemond usage looks like this after about a week: top - 00:42:49 up 22 days, 20:31, 2 users, load average: 2.08, 2.52, 2.54 Tasks: 271 total, 2 running, 269 sleeping, 0 stopped, 0 zombie Mem: 2074712k total, 1966420k used, 108292k free, 134520k buffers Swap: 1951800k total, 1113692k used, 838108k free, 547588k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7885 root 15 0 217m 68m 932 S0 3.4 0:40.84 /usr/lib/courier/courier-authlib/authdaemond 7884 root 15 0 216m 66m 928 S0 3.3 0:39.71 /usr/lib/courier/courier-authlib/authdaemond 7883 root 15 0 208m 66m 928 S0 3.3 0:38.41 /usr/lib/courier/courier-authlib/authdaemond 7886 root 15 0 217m 65m 928 S0 3.2 0:40.57 /usr/lib/courier/courier-authlib/authdaemond 7882 root 15 0 212m 65m 932 S0 3.2 0:38.97 /usr/lib/courier/courier-authlib/authdaemond Once I restart the service, usage looks much better: root 14565 0.0 0.0 4644 1132 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14569 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14570 0.0 0.0 4644 424 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14571 0.0 0.0 4688 1340 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14572 0.0 0.0 4812 1436 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond root 14573 0.0 0.0 4812 1476 ?S00:43 0:00 /usr/lib/courier/courier-authlib/authdaemond From /etc/courier/authlib/authdaemonrc: --- authmodulelist=authvchkpw daemons=5 DEFAULTOPTIONS= LOGGEROPTS= There is another post on the courier-users mailing list about this, user is also using a Gentoo environment and he was told to post on the vchkpw mailing list. Link included for reference: http://readlist.com/lists/lists.sourceforge.net/courier-users/0/3901.html Any input would be greatly appreciated. Matt !DSPAM:47507c6f32003496120983!
Re: [vchkpw] authdaemond memory leak?
Jan-Willem Regeer wrote: Look and see if you have the time to check with valgrind if you can find the error. It is in the ports tree, and looks for memory leakage by programs. Hope you find what the problem is. Note: I am not using authdaemond myself. Jan-Willem Regeer I tried running it through valgrind's memcheck. I don't see any issues whatsoever to be concerned with. I ran with it for about 12 hours of normal use. It looks to me that the program itself is collecting a lot of information, putting it in memory legitimately, and it simply uses gobs of it. Not a memory leak per se, but a programming mistake. Just so you know the output I got here was essentially the same when I only ran it for a few minutes... the small leaks detected here seem to be the same as when I ran the quick tests. Here's the output I got. I ran it with the --trace-children=yes option, so the process ID's (about three of them) represent the different children. ==45544== Is the main (parent) ==45549== is the worker thread (#2) ==45548== is the worker thread (#1) Here's the output. Billy ==45544== Memcheck, a memory error detector for x86-linux. ==45544== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==45544== Using valgrind-2.1.2.CVS, a program supervision framework for x86-linux. ==45544== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==45544== ==45544== My PID = 45544, parent PID = 45543. Prog and args are: ==45544==/usr/local/libexec/courier-authlib/authdaemond ==45544== For more details, rerun with: -v ==45544== ==45549== ==45548== ==45549== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==45548== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==45548== malloc/free: in use at exit: 21793446 bytes in 7800 blocks. ==45548== malloc/free: 39152 allocs, 31352 frees, 150866381 bytes allocated. ==45548== For counts of detected errors, rerun with: -v ==45548== searching for pointers to 7800 not-freed blocks. ==45549== malloc/free: in use at exit: 22053598 bytes in 7893 blocks. ==45549== malloc/free: 39651 allocs, 31758 frees, 152789639 bytes allocated. ==45549== For counts of detected errors, rerun with: -v ==45549== searching for pointers to 7893 not-freed blocks. ==45549== checked 10292868 bytes. ==45548== checked 10195776 bytes. ==45549== ==45549== 11 bytes in 1 blocks are definitely lost in loss record 1 of 12 ==45548== ==45548== 11 bytes in 1 blocks are definitely lost in loss record 1 of 12 ==45549==at 0x3C03772F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==45548==at 0x3C03772F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==45549==by 0x3C1038A2: strdup (in /lib/libc.so.5) ==45548==by 0x3C1038A2: strdup (in /lib/libc.so.5) ==45549==by 0x8049963: (within /usr/local/libexec/courier-authlib/authdaemond) ==45548==by 0x8049963: (within /usr/local/libexec/courier-authlib/authdaemond) ==45549==by 0x804B014: start (in /usr/local/libexec/courier-authlib/authdaemond) ==45548==by 0x804B014: start (in /usr/local/libexec/courier-authlib/authdaemond) ==45548== ==45549== ==45548== ==45549== ==45548== 34 bytes in 2 blocks are definitely lost in loss record 4 of 12 ==45549== 34 bytes in 2 blocks are definitely lost in loss record 4 of 12 ==45548==at 0x3C03772F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==45549==at 0x3C03772F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==45548==by 0x3C03CA4C: lt_emalloc (in /usr/local/lib/libltdl.so.4) ==45549==by 0x3C03CA4C: lt_emalloc (in /usr/local/lib/libltdl.so.4) ==45548==by 0x3C03D6F2: canonicalize_path (in /usr/local/lib/libltdl.so.4) ==45549==by 0x3C03D6F2: canonicalize_path (in /usr/local/lib/libltdl.so.4) ==45548==by 0x3C03E494: try_dlopen (in /usr/local/lib/libltdl.so.4) ==45549==by 0x3C03E494: try_dlopen (in /usr/local/lib/libltdl.so.4) ==45548== ==45548== ==45549== ==45548== 455840 bytes in 2590 blocks are possibly lost in loss record 11 of 12 ==45549== ==45549== 461296 bytes in 2621 blocks are possibly lost in loss record 11 of 12 ==45548==at 0x3C03772F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==45549==at 0x3C03772F: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==45548==by 0x3C2888CE: my_malloc (in /usr/local/lib/mysql/libmysqlclient.so.14) ==45549==by 0x3C2888CE: my_malloc (in /usr/local/lib/mysql/libmysqlclient.so.14) ==45548==by 0x3C2A3536: mysql_store_result (in /usr/local/lib/mysql/libmysqlclient.so.14) ==45549==by 0x3C2A3536: mysql_store_result (in /usr/local/lib/mysql/libmysqlclient.so.14) ==45548==by 0x3C26CE5A: vget_limits (in /usr/local/lib/courier-authlib/libauthvchkpw.so) ==45549==by 0x3C26CE5A: vget_limits (in /usr/local/lib/courier-authlib/libauthvchkpw.so) ==45548== ==45548== LEAK SUMMARY: ==45548==definitely lost: 45 bytes in 3 blocks. ==45549== ==45548==possibly
Re: [vchkpw] authdaemond memory leak?
Billy Newsom wrote: I just looked at how many times per day authdaemond logs this: received auth request it is around 6000 to 7000 times per day. That's about one every 12 seconds or so. Not a heavy use. In fact, I may have one bad auth per day, so all of those are successful. But I have noticed that the daemons are slowly increasing their memory usage without bounds. They are starting to cause the server to use swapfile space. Here is output from top: PID USERNAME PRI NICE SIZERES STATE C TIME WCPU CPU COMMAND 75331 root40 292M 13444K select 1 9:48 0.00% 0.00% authdaemond 75332 root 960 292M 13532K select 1 9:47 0.00% 0.00% authdaemond 75329 root40 2128K88K select 1 0:06 0.00% 0.00% authdaemond It got worse. I just reached 100% swapfile use today. last pid: 15020; load averages: 0.23, 0.15, 0.17 up 25+07:28:57 09:55:54 139 processes: 1 running, 129 sleeping, 9 zombie Mem: 299M Active, 55M Inact, 105M Wired, 21M Cache, 60M Buf, 13M Free Swap: 448M Total, 448M Used, 40K Free, 99% Inuse PID USERNAME PRI NICE SIZERES STATE C TIME WCPU CPU COMMAND 75331 root 960 393M 21908K select 1 13:13 0.00% 0.00% authdaemond 75332 root 960 393M 21976K select 0 13:13 0.00% 0.00% authdaemond imapd 75329 root40 2128K80K select 0 0:08 0.00% 0.00% authdaemond That's now 788MB of memory use. The web server uses 14MB, and imapd is under 100MB. I just restarted authdaemond. I guess I'm going to run a script that shuts it down nightly and brings it back up. Billy #date ; ls -l /var/run/authdaemond/ Wed Jun 22 20:43:50 CDT 2005 total 2 -rw-r--r-- 1 root courier 6 Jun 12 09:13 pid -rw--- 1 root courier 0 Jun 12 09:13 pid.lock srwxrwxrwx 1 root courier 0 Jun 12 09:13 socket (Ten days and 586 MB of memory hogging! Ouch. And that is 270MB resident.) Now, the reason I am only running two daemons should be obvious!! I saw how much memory each one used, and I looked for ways to reduce it. So I only run two now. Anyway, does anyone know of a memory leak detector that could find such a problem? As far as I know, a previous version of authdaemon had no such issue, but I upgraded around May 21, 2005 using the latest in the FreeBSD ports tree. I only see one change since that date, but that was specific to FreeBSD and the startup script (rc.d). (That may be good, because there was a bug in the restart of the one I got in May). So it seems like I have the 0.56 of the auth package, and I believe that is current. Thanks for your help, Billy
Re: [vchkpw] authdaemond memory leak?
On Jun 26, 2005, at 11:05 AM, Billy Newsom wrote: Billy Newsom wrote: I just looked at how many times per day authdaemond logs this: received auth request it is around 6000 to 7000 times per day. That's about one every 12 seconds or so. Not a heavy use. In fact, I may have one bad auth per day, so all of those are successful. But I have noticed that the daemons are slowly increasing their memory usage without bounds. They are starting to cause the server to use swapfile space. Here is output from top: PID USERNAME PRI NICE SIZERES STATE C TIME WCPU CPU COMMAND 75331 root40 292M 13444K select 1 9:48 0.00% 0.00% authdaemond 75332 root 960 292M 13532K select 1 9:47 0.00% 0.00% authdaemond 75329 root40 2128K88K select 1 0:06 0.00% 0.00% authdaemond It got worse. I just reached 100% swapfile use today. last pid: 15020; load averages: 0.23, 0.15, 0.17 up 25+07:28:57 09:55:54 139 processes: 1 running, 129 sleeping, 9 zombie Mem: 299M Active, 55M Inact, 105M Wired, 21M Cache, 60M Buf, 13M Free Swap: 448M Total, 448M Used, 40K Free, 99% Inuse PID USERNAME PRI NICE SIZERES STATE C TIME WCPU CPU COMMAND 75331 root 960 393M 21908K select 1 13:13 0.00% 0.00% authdaemond 75332 root 960 393M 21976K select 0 13:13 0.00% 0.00% authdaemond imapd 75329 root40 2128K80K select 0 0:08 0.00% 0.00% authdaemond That's now 788MB of memory use. The web server uses 14MB, and imapd is under 100MB. I just restarted authdaemond. I guess I'm going to run a script that shuts it down nightly and brings it back up. Billy #date ; ls -l /var/run/authdaemond/ Wed Jun 22 20:43:50 CDT 2005 total 2 -rw-r--r-- 1 root courier 6 Jun 12 09:13 pid -rw--- 1 root courier 0 Jun 12 09:13 pid.lock srwxrwxrwx 1 root courier 0 Jun 12 09:13 socket (Ten days and 586 MB of memory hogging! Ouch. And that is 270MB resident.) Now, the reason I am only running two daemons should be obvious!! I saw how much memory each one used, and I looked for ways to reduce it. So I only run two now. Anyway, does anyone know of a memory leak detector that could find such a problem? As far as I know, a previous version of authdaemon had no such issue, but I upgraded around May 21, 2005 using the latest in the FreeBSD ports tree. I only see one change since that date, but that was specific to FreeBSD and the startup script (rc.d). (That may be good, because there was a bug in the restart of the one I got in May). So it seems like I have the 0.56 of the auth package, and I believe that is current. Thanks for your help, Billy Look and see if you have the time to check with valgrind if you can find the error. It is in the ports tree, and looks for memory leakage by programs. Hope you find what the problem is. Note: I am not using authdaemond myself. Jan-Willem Regeer This message is authored under the license which can be found at http://x-istence.com/LICENSE smime.p7s Description: S/MIME cryptographic signature
