Bug#600563: parted-doc: Introduction to Partitioning: content moved to /dev/null
Package: parted-doc Version: 1.8.8.git.2008.03.24-11.1 Severity: minor In parted.info, section 2.1 (Introduction to Partitioning) says This manual used to introduce the reader to these systems and their working. This content has moved to the GNU Storage Guide. Unfortunately the GNU Storage Guide doesn't exist, as far as I can see. Is it possible to resurrect the content of that section until the GNU Storage Guide is ever released? (I don't really understand why anyone would remove the existing content before releasing it in another place, instead of after) -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash parted-doc depends on no packages. parted-doc recommends no packages. Versions of packages parted-doc suggests: ii parted 1.8.8.git.2008.03.24-11.1 The GNU Parted disk partition resi -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506423: wdutch: Incorrectly spelled words in wordlist (geconfisqeerd en geconfisqeerde)
Package: wdutch Version: 1:0.1e-44 Severity: minor I found two misspelled words in the wordlist: geconfisqeerd en geconfisqeerde. The wordlist alreade contains the correctly spelled versions (geconfisqueerd and geconfisqueerde). I checked the official Dutch word list (http://woordenlijst.org) to make sure that the spelling without u after the q is not correct. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages wdutch depends on: ii debconf [debconf-2.0]1.5.11etch2 Debian configuration management sy ii dictionaries-common 0.70.10 Common utilities for spelling dict wdutch recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420391: Still large memory footprint
I logged the memory usage during a number of days. The good news: it doesn't keep increasing. It changes at database reloads; sometimes it goes up, sometimes it goes down. The bad news: the maximum memory usage was VSZ=244548, RSS=205480, %MEM=40.1. Maybe I'm wrong, but I feel it's a bit ridiculous that a virus scanner takes more memory than mysql and apache and a number of other daemons combined. The average is lower than that though: about 20% - 30%. I also tracked the memory usage on another system (running the same version of clamav and Debian, except the kernel is 2.6.18-6-k7 instead of 2.6.18-6-amd64). On that system the memory usage is much lower; the maximum I saw was VSZ=37536, RSS=35460. -- Roel Schroeven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420391: Still large memory footprint
I made a log of the memory usage: Date/time STARTED ELAPSED %MEM VSZ RSS COMMAND 2008-02-06T23:10:01 22:12:25 57:36 10.6 74840 54708 clamd 2008-02-06T23:20:01 22:12:25 01:07:36 10.6 74840 54708 clamd 2008-02-06T23:30:01 22:12:24 01:17:37 11.7 80516 60308 clamd 2008-02-06T23:40:01 22:12:25 01:27:36 11.7 80516 60308 clamd ... 2008-02-07T00:10:01 22:12:24 01:57:37 11.7 80516 60308 clamd 2008-02-07T00:20:01 22:12:25 02:07:36 11.7 80516 60308 clamd 2008-02-07T00:30:01 22:12:24 02:17:37 21.1 132136 108192 clamd 2008-02-07T00:40:01 22:12:25 02:27:36 21.1 132136 108192 clamd ... Comparing with /var/log/clamav/clamd.log, it looks like the increases happen at the time of database reloads: Wed Feb 6 23:22:33 2008 - SelfCheck: Database modification detected. Forcing reload. Wed Feb 6 23:22:33 2008 - Reading databases from /var/lib/clamav Wed Feb 6 23:22:33 2008 - /var/spool/exim4/scan/1JMsf2-0003MD-L7/1JMsf2-0003MD-L7.eml: OK Wed Feb 6 23:22:35 2008 - Database correctly reloaded (206244 signatures) ... Thu Feb 7 00:22:59 2008 - SelfCheck: Database modification detected. Forcing reload. Thu Feb 7 00:22:59 2008 - Reading databases from /var/lib/clamav Thu Feb 7 00:22:59 2008 - /var/spool/exim4/scan/1JMtbR-0003Ui-5N/1JMtbR-0003Ui-5N.eml: OK Thu Feb 7 00:23:01 2008 - Database correctly reloaded (206247 signatures) That looks a bit like clamav bug 736 (https://wwws.clamav.net/bugzilla/show_bug.cgi?id=736) to me. The development team claims it's because of the way malloc/free works, and that the memory eventually will be reused by future mallocs. I'm not sure that that is consistent with what I'm seeing though. I'll let it run now and see if the memory usage keeps increasing, or if it tops out eventually. As a last resort I can of course just restart the process every day, but that's not a real solution. -- Roel Schroeven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420391: Still large memory footprint
Hi, I think there still is a problem. I'm using version 0.92~dfsg-1~volatile2 and I'm seeing large amounts of used memory when clamd has been running a while. For example, I currently see this line in top: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 27672 clamav15 0 127m 105m 896 S0 21.1 0:31.48 clamd That's about 24 hours after I restarted clamd. -- Roel Schroeven Tresco Engineering Kribbestraat 24, 2000 Antwerp, Belgium http://www.tresco.be [EMAIL PROTECTED] Tel. + 32 3 231 07 31 Fax + 32 3 829 03 71 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420391: Still large memory footprint
Stephen Gran wrote: Send me the output of find /var/lib/clamav -ls Here you go: $ find /var/lib/clamav -ls 127470504 drwxr-xr-x 4 clamav clamav 4096 Feb 6 11:21 /var/lib/clamav 127470724 drwxr-xr-x 2 clamav clamav 4096 Feb 6 08:57 /var/lib/clamav/main.inc 127470784 -rw-r--r-- 1 clamav clamav 3881 Dec 9 17:27 /var/lib/clamav/main.inc/main.fp 12747073 20 -rw-r--r-- 1 clamav clamav 17992 Apr 18 2007 /var/lib/clamav/main.inc/COPYING 12747075 640 -rw-r--r-- 1 clamav clamav 648469 Dec 9 17:27 /var/lib/clamav/main.inc/main.hdb 12746874 4248 -rw-r--r-- 1 clamav clamav4335069 Dec 9 17:27 /var/lib/clamav/main.inc/main.mdb 127468714 -rw-r--r-- 1 clamav clamav318 Dec 9 17:27 /var/lib/clamav/main.inc/main.info 12746939 4640 -rw-r--r-- 1 clamav clamav4735470 Dec 9 17:27 /var/lib/clamav/main.inc/main.db 12746945 14256 -rw-r--r-- 1 clamav clamav 14575772 Dec 9 17:27 /var/lib/clamav/main.inc/main.ndb 127470774 -rw-r--r-- 1 clamav clamav217 Apr 18 2007 /var/lib/clamav/main.inc/main.zmd 127470674 -rw--- 1 clamav clamav208 Feb 6 11:21 /var/lib/clamav/mirrors.dat 175809104 drwxr-xr-x 2 clamav clamav 4096 Feb 6 08:57 /var/lib/clamav/daily.inc 92405808 -rw-r--r-- 1 clamav clamav 4178 Jan 30 13:28 /var/lib/clamav/daily.inc/daily.hdb 175809124 -rw-r--r-- 1 clamav clamav 1224 Feb 5 17:21 /var/lib/clamav/daily.inc/daily.hdu 175800564 -rw-r--r-- 1 clamav clamav586 Feb 6 08:21 /var/lib/clamav/daily.inc/daily.info 17580914 28 -rw-r--r-- 1 clamav clamav 26923 Feb 5 17:21 /var/lib/clamav/daily.inc/daily.mdu 17580915 20 -rw-r--r-- 1 clamav clamav 17992 Sep 30 16:36 /var/lib/clamav/daily.inc/COPYING 92405818 -rw-r--r-- 1 clamav clamav 4456 Feb 3 15:21 /var/lib/clamav/daily.inc/daily.fp 175800544 -rw-r--r-- 1 clamav clamav 1168 Feb 1 17:42 /var/lib/clamav/daily.inc/daily.wdb 175800534 -rw-r--r-- 1 clamav clamav 90 Feb 2 17:42 /var/lib/clamav/daily.inc/daily.cfg 175810114 -rw-r--r-- 1 clamav clamav 2922 Sep 30 16:36 /var/lib/clamav/daily.inc/daily.zmd 17580045 28 -rw-r--r-- 1 clamav clamav 25483 Jan 18 16:28 /var/lib/clamav/daily.inc/daily.db 175810138 -rw-r--r-- 1 clamav clamav 4839 Jan 30 09:28 /var/lib/clamav/daily.inc/daily.ndu 175819114 -rw-r--r-- 1 clamav clamav 3031 Feb 2 00:42 /var/lib/clamav/daily.inc/daily.pdb 17580058 292 -rw-r--r-- 1 clamav clamav 294518 Feb 6 07:21 /var/lib/clamav/daily.inc/daily.ndb 9240582 1972 -rw-r--r-- 1 clamav clamav2013506 Feb 6 08:21 /var/lib/clamav/daily.inc/daily.mdb -- Roel Schroeven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420391: Still large memory footprint
Ronny Adsetts wrote: Stephen Gran said at 06/02/2008 11:36: This one time, at band camp, Roel Schroeven said: Stephen Gran wrote: Send me the output of find /var/lib/clamav -ls Here you go: Hmm, nothing unusual there. I was hoping to see 3rd party databases or doubling of standard databases or something to explain your useage. I'm only seeing: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND clamav1815 0.0 7.6 108680 34456 ?Ss Feb05 0:31 /usr/sbin/clamd Not how much lower my RSS is compared to your output. And this is with some 3rd party databases ! I don't get it. Just to add to this, I'm seeing fairly high memory usage here on amd64: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND clamav3202 0.2 10.7 301080 221528 ? Ssl Feb02 14:18 /usr/sbin/clamd $ uname -a Linux allanon 2.6.18-6-amd64 #1 SMP Wed Jan 23 06:27:23 UTC 2008 x86_64 GNU/Linux Mine is amd64 too: $ uname -a Linux rack01 2.6.18-6-amd64 #1 SMP Wed Jan 23 06:27:23 UTC 2008 x86_64 GNU/Linux Maybe that has something to do with it? -- Roel Schroeven Tresco Engineering Kribbestraat 24, 2000 Antwerp, Belgium http://www.tresco.be [EMAIL PROTECTED] Tel. + 32 3 231 07 31 Fax + 32 3 829 03 71 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
