Bug#987008: Grub fails to find LVM volume after previous LV rename

[Ronny Adsetts]

Source: grub2
Followup-For: Bug #987008

Dear Maintainer,

Is there a chance that the patch in comment #10 could be applied to the Debian
package? Judging by the unstream ticket, there's little interest in applying
the patch there - I've just commented on the ticket asking if it couild be
applied upstream which might remind people it's there.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987008#10

I was bitten by this bug a couple of days ago when one of our servers failed to
boot following a power outage.

Thanks for your time.

Ronny


-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-20-amd64 (SMP w/20 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 03/09/2020 13:42:
> 
> that's great, I have opened an issue upstream, let's see what they
> think.

Thanks. I'll monitor the issue.

Ronny

-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Hi Bernhard,

Bernhard Übelacker wrote on 01/09/2020 17:55:
[...]
>> So running with the patched cups packages seems to fix the "invalid
>> free" on a test print. I've restored the systemd service file to
>> remove valgrind so let's see how we go on a day's printing. :-).
> 
> Any news in this regard?

Good news. I don't see any "invalid free" reports.

Can I thank you again for your time and energy in solving this. It really is 
appreciated.

Let me know if there's anything I can do to help get this patch upstreamed.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 26/08/2020 23:10:
> 
> I tried to have a look and I get the feeling that there is a
> disagreement if the attribute "printer-alert" is of type IPP_TAG_TEXT
> or IPP_TAG_STRING.
> 
> Also it is the only line I found at a glance that calls ippAddString
> with a IPP_TAG_STRING.
> 
> Other attributes of type IPP_TAG_STRING seem to get added by a call
> to ippAddOctetString.
> 
> But still I am not sure which of STRING or TEXT is the right one.
> 
> Below patch is an attempt to add "printer-alert" in
> copy_printer_attrs by using ippAddOctetString.
> 
> The important change is in scheduler/ipp.c, the changes to
> backend/ipp.c should just mark another questionable place.
> 
> I could not test this change as I can not reproduce the crash - so it
> is untested.

Hi Bernhard,

So running with the patched cups packages seems to fix the "invalid free" on a 
test print. I've restored the systemd service file to remove valgrind so let's 
see how we go on a day's printing. :-).

Incidentally, stopping the cups service (new packages) after a single print job 
when under valgrind gave this in case it's related:

Aug 28 10:03:59 samba-prn-01.graysofwestminster.co.uk systemd[1]: Stopping CUPS 
Scheduler...
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238== 
Invalid free() / delete / delete[] / realloc()
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  at 0x48369AB: free (vg_replace_malloc.c:538)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4C73629: check_free (dlerror.c:202)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4C73629: check_free (dlerror.c:186)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4C73AB1: free_key_mem (dlerror.c:221)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4C73AB1: __dlerror_main_freeres (dlerror.c:239)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4BECB71: __libc_freeres (in /usr/lib/x86_64-linux-gnu/libc-2.28.so)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x482B19E: _vgnU_freeres (vg_preloaded.c:75)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4ABDE89: __run_exit_handlers (exit.c:132)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4ABDEB9: exit (exit.c:139)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  by 0x4AA80A1: (below main) (libc-start.c:342)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
Address 0x4a5dd94 is in a r-- mapped file 
/usr/lib/x86_64-linux-gnu/libcups.so.2 segment
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238== 
HEAP SUMMARY:
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
   in use at exit: 829,720 bytes in 16,197 blocks
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
 total heap usage: 131,007 allocs, 114,811 frees, 25,289,313 bytes allocated
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238== 
LEAK SUMMARY:
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  definitely lost: 51,468 bytes in 519 blocks
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  indirectly lost: 65,751 bytes in 4 blocks
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
possibly lost: 0 bytes in 0 blocks
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
  still reachable: 712,501 bytes in 15,674 blocks
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==  
   suppressed: 0 bytes in 0 blocks
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238== 
Rerun with --leak-check=full to see details of leaked memory
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238==
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238== 
For lists of detected and suppressed errors, rerun with: -s
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk valgrind[5238]: ==5238== 
ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk systemd[1]: cups.service: 
Succeeded.
Aug 28 10:04:00 samba-prn-01.graysofwestminster.co.uk systemd[1]: Stopped CUPS 
Scheduler.
Aug 28 10:04:12 samba-prn-01.graysofwestm

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 27/08/2020 12:00:
> unfortunately I don't have any pointers on that httpAddrGetList.
> 
> So you were able to build a package?

Yes, I patched out the fail (typo included for free):

Index: cups-2.3.3/cups/testhttp.c
===
--- cups-2.3.3.orig/cups/testhttp.c 2020-04-27 18:04:29.0 +
+++ cups-2.3.3/cups/testhttp.c  2020-08-27 10:48:23.991753579 +
@@ -416,8 +416,10 @@
 }
 else
 {
-  failures ++;
-  puts("FAIL");
+  // Comment out the following failure as something in
+  // cowbuilder causes it to fail
+  //failures ++;
+  puts("FAIL (ignored because user of cowbuilder results in a fail");
 }

/*

:-).

I'll install the patched packages outside of office hours and give them a test. 
I might be able to do this today, otherwise it will be first thing in the 
morning.

> One additional note: I guess with "quilt refresh" any new changes
> get added to the last patch. A 'dpkg-source --commit' would create a
> new separate patch file.

I figured out creating new patches with quilt eventually. :-). This page was 
most useful:

https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 26/08/2020 23:10:
[...]
> 
> Below patch is an attempt to add "printer-alert" in
> copy_printer_attrs by using ippAddOctetString.
> 
> The important change is in scheduler/ipp.c, the changes to
> backend/ipp.c should just mark another questionable place.
> 
> I could not test this change as I can not reproduce the crash - so it
> is untested.

Hi Bernhard,

Thanks for the patch. After figuring out using "quilt refresh" I got a source 
package built with the patch included. Unfortunately my build attempt in 
cowbuilder hits this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916433

With this test fail:

httpAddrGetList(backports.graysofwestminster.co.uk): FAIL

I obviously managed to "fix" this once as I already built the package once. 
Going back through my google history to try and "fix" it again. And make a note 
of it this time. :-).

I don't suppose you have any pointers on solving this one do you? Probably 
something missing in the build chroot...

Thanks.

Ronny

-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 25/08/2020 22:07:
> Am 25.08.20 um 14:40 schrieb Ronny Adsetts:
>> In which case a backport of valgrind would be dead handy. :-).
> 
> You might be able to build one yourself:
> (maybe inside a VM too, because several build dependencies get installed ...)
[...]

Thanks. I rebuilt it fine. Result look much better:

Aug 26 15:42:57 samba-prn-01 systemd[1]: Started CUPS Scheduler.
Aug 26 15:42:57 samba-prn-01 valgrind[31788]: ==31788== Memcheck, a memory 
error detector
Aug 26 15:42:57 samba-prn-01 valgrind[31788]: ==31788== Copyright (C) 
2002-2017, and GNU GPL'd, by Julian Seward et al.
Aug 26 15:42:57 samba-prn-01 valgrind[31788]: ==31788== Using Valgrind-3.16.1 
and LibVEX; rerun with -h for copyright info
Aug 26 15:42:57 samba-prn-01 valgrind[31788]: ==31788== Command: 
/usr/sbin/cupsd -l
Aug 26 15:42:57 samba-prn-01 valgrind[31788]: ==31788==
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788== Invalid free() / delete 
/ delete[] / realloc()
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==at 0x48369AB: free 
(vg_replace_malloc.c:538)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x4A2443D: 
ipp_free_values (ipp.c:6324)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x4A243A7: 
ippDelete (ipp.c:1755)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x4A243A7: 
ippDelete (ipp.c:1729)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x11CCE3: 
cupsdWriteClient (client.c:2563)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x156D36: 
cupsdDoSelect (select.c:485)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x1142F4: main 
(main.c:847)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==  Address 0x68f1e04 is 4 
bytes inside a block of size 23 alloc'd
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==at 0x4837B65: calloc 
(vg_replace_malloc.c:760)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x4A34DD0: 
_cupsStrAlloc (string.c:107)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x4A234F5: 
ippAddString (ipp.c:957)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x13076D: 
copy_printer_attrs (ipp.c:4894)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x13DCCD: 
get_printer_attrs (ipp.c:7365)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x13DCCD: 
cupsdProcessIPPRequest (ipp.c:457)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x11DD24: 
cupsdReadClient (client.c:1812)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x156C04: 
cupsdDoSelect (select.c:480)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==by 0x1142F4: main 
(main.c:847)
Aug 26 15:55:14 samba-prn-01 valgrind[31788]: ==31788==

Hopefully this fives you something more helpful to go on...

Thanks again for all your time and energy on this so far.

Ronny

-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 25/08/2020 11:50:
> Am 25.08.20 um 11:02 schrieb Ronny Adsetts:
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ??? 
>> (in /usr/sbin/cupsd)
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5F44D23F: ???
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==
>>
>> Does that give any further insight?
> 
> Is the cups-daemon-dbgsym installed and from the same
> source as the cups-daemon package?
> 
> Does following command show the same BuildID ?

The lack of debug symbols in valgrind could possibly be this bug - the symptoms 
appear to be the same:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942614

My output from valgrind contained this:

Aug 25 09:49:17 samba-prn-01 valgrind[28088]: --28088-- WARNING: Serious error 
when reading debug info
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: --28088-- When reading debug info 
from /usr/sbin/cupsd:
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: --28088--debuginfo section 
duplicates a section in the main ELF file

In which case a backport of valgrind would be dead handy. :-).

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 25/08/2020 11:50:
> Am 25.08.20 um 11:02 schrieb Ronny Adsetts:
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ??? 
>> (in /usr/sbin/cupsd)
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5F44D23F: ???
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==
>>
>> Does that give any further insight?
> 
> Is the cups-daemon-dbgsym installed and from the same
> source as the cups-daemon package?

Yes, appears to be:

root@samba-prn-01:~# dpkg -l cups-daemon cups-daemon-dbgsym
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
+++-==-===--
ii  cups-daemon2.3.3-1~bpo10+1 amd64Common UNIX Printing System(
ii  cups-daemon-dbgsym 2.3.3-1~bpo10+1 amd64debug symbols for cups-daemo

> Does following command show the same BuildID ?
> 
> # file /usr/sbin/cupsd 
> /usr/lib/debug/.build-id/8a/de7144c28e948515ffa5b45d70e4e02e008e17.debug
> /usr/sbin/cupsd:  ELF 
> 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
> interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
> BuildID[sha1]=8ade7144c28e948515ffa5b45d70e4e02e008e17, stripped
> /usr/lib/debug/.build-id/8a/de7144c28e948515ffa5b45d70e4e02e008e17.debug: ELF 
> 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
> interpreter *empty*, for GNU/Linux 3.2.0, 
> BuildID[sha1]=8ade7144c28e948515ffa5b45d70e4e02e008e17, with debug_info, not 
> stripped

> # dpkg -S de7144c28e948515ffa5b45d70e4e02e008e17
> cups-daemon-dbgsym: 
> /usr/lib/debug/.build-id/8a/de7144c28e948515ffa5b45d70e4e02e008e17.debug

The BuildID is different (probably as I rebuilt) but it seems to be right:

root@samba-prn-01:~# file /usr/sbin/cupsd /usr/lib/debug/.build-id/6d/*| grep 
6dc083ea4548b510e5e2e225f09345d3ef998629
/usr/sbin/cupsd:  ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=6dc083ea4548b510e5e2e225f09345d3ef998629, stripped
/usr/lib/debug/.build-id/6d/c083ea4548b510e5e2e225f09345d3ef998629.debug: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, 
interpreter *empty*, for GNU/Linux 3.2.0, 
BuildID[sha1]=6dc083ea4548b510e5e2e225f09345d3ef998629, with debug_info, not 
stripped

root@samba-prn-01:~# dpkg -S c083ea4548b510e5e2e225f09345d3ef998629
cups-daemon-dbgsym: 
/usr/lib/debug/.build-id/6d/c083ea4548b510e5e2e225f09345d3ef998629.debug

It's beyond me why the debug symbols are not being picked up.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 25/08/2020 09:34:
> 
> Adding the line above would just appear in 'journalctl -e -u cups.service'.
> Otherwise one could add the option '--log-file=/tmp/valgrind' to redirect
> and separate the additional output of valgrind.
> 
> I have also not yet run valgrind that way, but I would expect either the crash
> happen the same way, therefore process would end and maybe automatically 
> restarted.
> 
> It might also just print something and continue or the issue does not happen
> at all when running under valgrind, I cannot be sure.

OK, thanks. I have cups running under valgrind. Running a test print from a 
Windows 10 box triggers the error and Valgrind gives this output:

Aug 25 09:49:17 samba-prn-01 systemd[1]: Started CUPS Scheduler.
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: ==28088== Memcheck, a memory 
error detector
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: ==28088== Copyright (C) 
2002-2017, and GNU GPL'd, by Julian Seward et al.
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: ==28088== Using Valgrind-3.14.0 
and LibVEX; rerun with -h for copyright info
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: ==28088== Command: 
/usr/sbin/cupsd -l
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: ==28088==
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: --28088-- WARNING: Serious error 
when reading debug info
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: --28088-- When reading debug info 
from /usr/sbin/cupsd:
Aug 25 09:49:17 samba-prn-01 valgrind[28088]: --28088--debuginfo section 
duplicates a section in the main ELF file
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088== Invalid free() / delete 
/ delete[] / realloc()
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==at 0x48369AB: free 
(vg_replace_malloc.c:530)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x4A2443D: 
ipp_free_values (ipp.c:6324)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x4A243A7: 
ippDelete (ipp.c:1755)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x4A243A7: 
ippDelete (ipp.c:1729)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x11CCE3: ??? (in 
/usr/sbin/cupsd)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==  Address 0x65f1e94 is 4 
bytes inside a block of size 23 alloc'd
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==at 0x4837B65: calloc 
(vg_replace_malloc.c:752)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x4A34DD0: 
_cupsStrAlloc (string.c:107)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x4A234F5: 
ippAddString (ipp.c:957)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ??? (in 
/usr/sbin/cupsd)
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5F44D23F: ???
Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==

Does that give any further insight?

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Morning Bernard,

Bernhard Übelacker wrote on 25/08/2020 02:18:
> Am 24.08.20 um 13:12 schrieb Ronny Adsetts:

>>> Otherwise running cupsd within valgrind could also give some
>>> hints.
>> 
>> I'll see if I can do this. I'll have to schedule some down time so
>> it won't be immediate (or possibly even quick).
> 
> I tried to run it in a VM and tested with some virtual PDF and PS
> printer. Following were the configuration changes to have it run
> under valgrind.
> 
> nano /lib/systemd/system/cups.service
> 
> -ExecStart=/usr/sbin/cupsd -l +# ExecStart=/usr/sbin/cupsd -l 
> +ExecStart=/usr/bin/valgrind --trace-children=no /usr/sbin/cupsd -l
> 
> systemctl daemon-reload systemctl stop cups.service systemctl start
> cups.service
> 
> But I don't know if that might create a problem perfomance wise.
> 
> I have tried to build with AddressSanitizer, but the build itself
> makes trouble and the resulting binary is not able to print...

I've never used valgrind before. How long should I run it this way for? How do 
I get the result of running it to send to you?

Sorry for the newbie questions. :-).

Ronny

-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

f77c1a in malloc_printerr (
str=str@entry=0x7f4c2607a43b "free(): invalid pointer") at malloc.c:5341
No locals.
#4  0x7f4c25f7942c in _int_free (av=, p=,
have_lock=) at malloc.c:4165
size = 4294967296
fb = 
nextchunk = 
nextsize = 
nextinuse = 
prevsize = 
--Type  for more, q to quit, c to continue without paging--c
bck = 
fwd = 
__PRETTY_FUNCTION__ = "_int_free"
#5  0x7f4c260f543e in ipp_free_values (attr=attr@entry=0x558e903207d0, 
element=element@entry=0, count=1) at ipp.c:6324
i = 
value = 0x558e903207f0
#6  0x7f4c260f53a8 in ippDelete (ipp=0x558e90317170) at ipp.c:1755
attr = 0x558e903207d0
next = 0x558e902d2310
attr = 
next = 
#7  ippDelete (ipp=0x558e90317170) at ipp.c:1729
attr = 
next = 
#8  0x558e8fde4ce4 in cupsdWriteClient (con=0x558e90351530) at client.c:2563
bytes = 
field_col = 
bufptr = 
bufend = 
ipp_state = 
#9  0x558e8fe1ed37 in cupsdDoSelect (timeout=) at 
select.c:485
i = 
event = 0x7f4c247a9010
nfds = 1
fdptr = 0x558e902c1950
pfd = 
count = 
#10 0x558e8fddc2f5 in main (argc=, argv=) at 
main.c:847
i = 2
opt = 
close_all = 
disconnect = 
fg = 
run_as_child = 
print_profile = 
fds = 1
con = 
job = 
lis = 
current_time = 
activity = 
senddoc_time = 1598265667
expire_time = 1598265667
report_time = 0
event_time = 1598265646
timeout = 1
limit = {rlim_cur = 524288, rlim_max = 524288}
action = {__sigaction_handler = {sa_handler = 0x558e8fdf34a0 
, sa_sigaction = 0x558e8fdf34a0 }, sa_mask = 
{__val = {81920, 0 }}, sa_flags = 0, sa_restorer = 0x0}
netif_time = 1598265627
service_idle_exit = 0
(gdb)


> Otherwise running cupsd within valgrind could also give some hints.

I'll see if I can do this. I'll have to schedule some down time so it won't be 
immediate (or possibly even quick).

> This bug might describe the same issue, unfortunately also without solution:
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1846334
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1826648
> https://marc.info/?l=openbsd-ports=157331902608071=2

The first two, certainly, look the same.

It might be coincident but both the launchpad bugs seems to be Samsung printers 
which is what we currently have. Could a bad PPD be causing this?

> https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L1729
> https://sources.debian.org/src/cups/2.3.3-2/scheduler/client.c/#L2244

Looks like we're hitting the default part of the case statement that frees 
memory and then trying to free the invalid pointer:

https://sources.debian.org/src/cups/2.3.3-2/cups/ipp.c/#L6324

My C foo is insufficient to get much further than this I'm afraid.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Package: cups
Version: 2.3.3-1~bpo10+1
Followup-For: Bug #961345

Dear Maintainer,

I'm running the Testing version of cups recompiled for Buster. I'm seeing the
same "invalid pointer" issue as the reporter.

Backtrace for a coredump is below. Please let me know if there's any other
information I can provide in order to help get a solution for this issue. It's
disrupting our printing significantly:

root@samba-prn-01:~# coredumpctl gdb 27338
   PID: 27338 (cupsd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Mon 2020-07-06 17:01:15 BST (17h ago)
  Command Line: /usr/sbin/cupsd -l
Executable: /usr/sbin/cupsd
 Control Group: /system.slice/cups.service
  Unit: cups.service
 Slice: system.slice
   Boot ID: 0fcad17ac3cd455b9f660e247188c9f5
Machine ID: d5fab4a49a044739a79685e71c58019c
  Hostname: samba-prn-01.graysofwestminster.co.uk
   Storage: 
/var/lib/systemd/coredump/core.cupsd.0.0fcad17ac3cd455b9f660e247188c9f5.27338.159405127500.lz4
   Message: Process 27338 (cupsd) of user 0 dumped core.

Stack trace of thread 27338:
#0  0x7f5c88cfb7bb __GI_raise (libc.so.6)
#1  0x7f5c88ce6535 __GI_abort (libc.so.6)
#2  0x7f5c88d3d508 __libc_message (libc.so.6)
#3  0x7f5c88d43c1a malloc_printerr (libc.so.6)
#4  0x7f5c88d4542c _int_free (libc.so.6)
#5  0x7f5c88ec143e n/a (libcups.so.2)
#6  0x7f5c88ec13a8 ippDelete (libcups.so.2)
#7  0x55c691e34ce4 cupsdWriteClient (cupsd)
#8  0x55c691e6ed37 cupsdDoSelect (cupsd)
#9  0x55c691e2c2f5 main (cupsd)
#10 0x7f5c88ce809b __libc_start_main (libc.so.6)
#11 0x55c691e2d5da _start (cupsd)

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/cupsd...Reading symbols from 
/usr/lib/debug/.build-id/6d/c083ea4548b510e5e2e225f09345d3ef998629.debug...done.
done.
[New LWP 27338]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/cupsd -l'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f5c88ce6535 in __GI_abort () at abort.c:79
#2  0x7f5c88d3d508 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f5c88e4828d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f5c88d43c1a in malloc_printerr (
str=str@entry=0x7f5c88e4643b "free(): invalid pointer") at malloc.c:5341
#4  0x7f5c88d4542c in _int_free (av=, p=,
have_lock=) at malloc.c:4165
#5  0x7f5c88ec143e in ?? () from /lib/x86_64-linux-gnu/libcups.so.2
#6  0x7f5c88ec13a8 in ippDelete () from /lib/x86_64-linux-gnu/libcups.so.2
#7  0x55c691e34ce4 in cupsdWriteClient (con=0x55c692502310)
at client.c:2563
#8  0x55c691e6ed37 in cupsdDoSelect (timeout=)
at select.c:485
#9  0x55c691e2c2f5 in main (argc=, argv=)
at main.c:847
(gdb) quit


Thanks for your time.

Ronny


-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.3.3-1~bpo10+1
ii  cups-common2.3.3-1~bpo10+1
ii  cups-core-drivers  2.3.3-1~bpo10+1
ii  cups-daemon2.3.3-1~bpo10+1
ii  cups-filters   1.27.4-1
ii  cups-ppdc  2.3.3-1~bpo10+1
ii  cups-server-common 2.3.3-1~bpo10+1
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u3
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libcups2 

Bug#704764: php5: CVE-2011-1398 results in PCI compliance scan fail

[Ronny Adsetts]

Package: php5
Version: 5.3.3-7+squeeze15
Severity: important

CVE-2011-1398 is unfixed in Debian Squeeze and is classified by Trustwave.com 
as a PCI compliance scan fail. As far as I can tell there's no way to mitigate
the problem short of building my own packages with upstream patches. I'm not
sure that this is within my capabilities as the initial fixes for this issue
were I think incomplete and resulted in CVE-2012-4388.

I've searched the Debian bugs for PHP and can't find reference to this issue.

Is there a change that CVE-2011-1398 (and therefore CVE-2012-4388) will be
fixed for Debian Squeeze with a security release?

Thanks.

Ronny


-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php5 depends on:
ii  libapache2-mod-php55.3.3-7+squeeze15 server-side, HTML-embedded scripti
ii  php5-common5.3.3-7+squeeze15 Common files for packages built fr

php5 recommends no packages.

php5 suggests no packages.

-- 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#551564: Further information and confirmation bug still exists

[Ronny Adsetts]

Bdale Garbee said at 19/11/2012 17:14:
 Ronny Adsetts ronny.adse...@amazinginternet.com writes:
 
 Not sure what need to be done to get the packaged version of
 amserverconfig working but it would be appreciated very much. 
 
 My amanda server config pre-dates the existence of amserverconfig by
 more than a decade, so I've just never had any reason to run it... which
 is why I never realized it was broken.

Fair enough. I needed to set up a second Amanda run which is why I came across 
it. :-).

 I'll try to look at it before I upload 3.3.2-1, coming soon.

Brilliant, much appreciated.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#551564: Further information and confirmation bug still exists

[Ronny Adsetts]

Hi,

This bug still exists in Amanda 1:3.3.1-3~bpo6 (squeeze-backports). In 
addition, the templates directory 
/usr/share/doc/amanda-common/examples/template.d referenced in the fixes 
required to use amserverconfig appears to be no longer shipped.

Not sure what need to be done to get the packaged version of amserverconfig 
working but it would be appreciated very much.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#687315: /usr/sbin/mysqld: Upgrade to SQUEEZE results in wrong gid for mysql user

[Ronny Adsetts]

Package: mysql-server-core-5.1
Version: 5.1.63-0+squeeze1
Severity: normal
File: /usr/sbin/mysqld


Hi,

Just debugging why creation of temporary tables fails following an upgrade to
SQUEEZE. Turns out that the mysql user record is wrong

Running SQL like CREATE TABLE blah SELECT * FROM fred results in an error
similar to:
Can't create file './chill@002dtmp/contact.frm' (errno: 9)

Checking the ownership of the temp file showed:

drwx--   2 mysql crontab 4096 Sep 11 17:04 chill@002dtmp

Checking the user shows the problem:

# id mysql
uid=106(mysql) gid=101(crontab) groups=101(crontab)

Fixing the gid field in /etc/passwd fixes the problem.

Google shows other people having a similar problem (though possibly unrelated) 
so hopefully this helps document the issue. I suspect the problem has been
fixed long ago.

Thanks.

Ronny

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mysql-server-core-5.1 depends on:
ii  libc6   2.11.3-3 Embedded GNU C Library: Shared lib
ii  libgcc1 1:4.4.5-8GCC support library
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libwrap07.6.q-19 Wietse Venema's TCP wrappers libra
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

mysql-server-core-5.1 recommends no packages.

mysql-server-core-5.1 suggests no packages.

-- 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#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

Bdale Garbee said at 20/03/2012 10:51:
 On Thu, 08 Mar 2012 16:24:13 +, Ronny Adsetts 
 ronny.adse...@amazinginternet.com wrote:
 After my failed attempt to close the bug, it's come to light that
 amanda is only intermittently using 'dump' instead of 'xfsdump' for
 xfs partitions. 
 
 I'm about to upload amanda 3.3.1-1 to unstable.  If you're able to try
 it, I'd love to know if it solves the problem for you.

I'll see if I can give it a try.

At this stage though, I *think* it may be operator error. The backup runs on 
Squeeze are simply taking longer than they were on Etch for our main fileserver 
- I've not yet got to the bottom of why. My LVM snapshot script made 
assumptions about how long the backups would take in the worst case and was 
sometimes removing the snapshots before Amanda had started dumping them hence 
Amanda using 'dump' rather than 'xfsdump'.

I'll verify this in a couple of days once all partitions have had a full dump 
and close the ticket if it is the case.

Thank you for all your help (and continued packaging of Amanda) and apologies 
for wasting your time.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#663970: [Packaging] Bug#663970: munin-node ignores timeout config option

[Ronny Adsetts]

Holger Levsen said at 18/03/2012 13:48:
 
 thanks for your bug report. Could you please file it in the munin trac bug 
 tracker? If not, I will, but as you know way better about your problem, it 
 would be better if you'd do it ;-) To do that, go to
 
 http://munin-monitoring.org/newticket
 
 which (sadly) needs
 
 http://munin-monitoring.org/register
 
 When you've done this, please send a short mail to 663...@bugs.debian.org 
 mentioning the ticket number you got.

Hi Holger,

Ticket is 1209:
http://munin-monitoring.org/ticket/1209

 Also, have you seen http://munin-monitoring.org/wiki/rrdcached ?

Yes thanks, that's primarily what I used to get rrcached going. Bit fiddly but 
got there.

Incidentally, contrary to the bug report, using rrdcached didn't totally work 
around the problem. It was a little faster which meant it sometimes worked. To 
fully work around the problem, I reduced the number of partitions diskstats was 
scanning by filtering out the LVM snapshots we use for backups.

Thanks for your help and for packaging munin. Much appreciated. :-).

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#663970: munin-node ignores timeout config option

[Ronny Adsetts]

Package: munin-node
Version: 1.999.4603-1
Severity: normal


This is for munin* from experimental on Squeeze.

My system runs under quite a heavy load for most of the day and has lots of
partitions. This results in the diskstats plugin taking lots of time to run.

When munin starts writing the rrd data out, munin-node times out its connection
resulting in no further graphs being drawn for that host. The timeout is the
default 5 seconds. Adding timeout 30 to munin-node-conf has no effect.
Telneting to munin-node fconfirms the timeout remains 5 seconds.

Running munin-update manaully results in the following trimmed output:

munin@vimes:~$ /usr/share/munin/munin-update --nofork --debug --host vimes

2012/03/14 10:31:46 [FETCH from diskstats] Storing 1.759004 in avgwrrqsz
.
2012/03/14 10:31:52 [FATAL] Socket read from vimes.amazing-internet.net failed. 
 Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 391
2012/03/14 10:31:52 [ERROR] Error in node communication with 
vimes.amazing-internet.net/172.16.1.19:4949: [FATAL] Socket read from 
vimes.amazing-internet.net failed.  Terminating process. at 
/usr/share/perl5/Munin/Master/UpdateWorker.pm line 391
2012/03/14 10:31:52 [WARNING] Failed worker 
amazing-internet.net;vimes.amazing-internet.net

In the end I worked around this by figuring out how to use rrdcached which
prevents the 5 second timeout being hit.

Let me know if you need any further information.

Ronny


-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages munin-node depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  gawk   1:3.1.7.dfsg-5GNU awk, a pattern scanning and pr
ii  libnet-server-perl 0.97-1An extensible, general perl server
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  munin-common   1.999.4603-1  network-wide graphing framework (c
ii  munin-plugins-core [mu 1.999.4603-1  network-wide graphing framework (p
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  procps 1:3.2.8-9 /proc file system utilities

Versions of packages munin-node recommends:
ii  libnet-snmp-perl5.2.0-4  Script SNMP connections
ii  munin-plugins-core  1.999.4603-1 network-wide graphing framework (p

Versions of packages munin-node suggests:
pn  acpi | lm-sensors   none   (no description available)
pn  ethtool none   (no description available)
pn  hdparm  none   (no description available)
pn  libcache-cache-perl none   (no description available)
ii  libcrypt-ssleay-perl0.57-2   Support for https protocol in LWP
ii  libdbd-mysql-perl   4.016-1  Perl5 database interface to the My
pn  libdbd-pg-perl  none   (no description available)
pn  liblwp-useragent-determ none   (no description available)
pn  libnet-irc-perl none   (no description available)
pn  libtext-csv-xs-perl none   (no description available)
ii  libwww-perl 5.836-1  Perl HTTP/WWW client/server librar
ii  libxml-simple-perl  2.18-3   Perl module for reading and writin
pn  logtail none   (no description available)
ii  munin   1.999.4603-1 network-wide graphing framework (g
pn  munin-async none   (no description available)
pn  munin-java-plugins  none   (no description available)
ii  munin-plugins-extra 1.4.6-1~bpo60+1  network-wide graphing framework (u
ii  mysql-client5.1.49-3 MySQL database client (metapackage
ii  mysql-client-5.1 [mysql 5.1.49-3 MySQL database client binaries
ii  net-tools   1.60-23  The NET-3 networking toolkit
ii  python  2.6.6-3+squeeze6 interactive high-level object-orie
pn  rubynone   (no description available)
ii  smartmontools   5.39.1+svn3124-2 control and monitor storage system

-- Configuration Files:
/etc/munin/munin-node.conf changed:
log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid
timeout 30
background 1
setsid 1
user root
group root
ignore_file [\#~]$
ignore_file DEADJOE$ 
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
ignore_file \.pod$
cidr_allow 127.0.0.1/32
cidr_allow 172.16.1.19/32
cidr_allow 172.16.1.20/32
host *
port 4949


-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of 

Bug#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

Hi Bdale,

After my failed attempt to close the bug, it's come to light that amanda is 
only intermittently using 'dump' instead of 'xfsdump' for xfs partitions. See 
the two attached sendbackup debug files for the same partition on consecutive 
days. The first from eysterday runs xfsdump, the second from today runs dump. 
Very odd.

The main trouble is that when it runs dump, it fails to complete and retires 
running in to office hours which is very boring when the disk sub-sytem is 
being hammered whilst people are trying to work. :-)

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 



1331197420.112165: sendbackup: pid 31205 ruid 34 euid 34 version 2.6.1p2: start 
at Thu Mar  8 09:03:40 2012
1331197420.112252: sendbackup: Version 2.6.1p2
1331197420.112979: sendbackup: pid 31205 ruid 34 euid 34 version 2.6.1p2: 
rename at Thu Mar  8 09:03:40 2012
1331197420.113861: sendbackup:   Parsed request as: program `DUMP'
1331197420.113876: sendbackup:  disk `/snapshots/cvsroot'
1331197420.113885: sendbackup:  device `/snapshots/cvsroot'
1331197420.113894: sendbackup:  level 1
1331197420.113903: sendbackup:  since NODATE
1331197420.113910: sendbackup:  options `'
1331197420.114099: sendbackup: start: 
vimes.amazing-internet.net:/snapshots/cvsroot lev 1
1331197420.114187: sendbackup: pipespawnv: stdoutfd is 50
1331197420.114254: sendbackup: Spawning /bin/gzip /bin/gzip --fast in pipeline
1331197420.114648: sendbackup: dump: pid 31207: /bin/gzip1331197420.114702: 
sendbackup:  --fast1331197420.114715: sendbackup: 
1331197420.193839: sendbackup: dumping device '/snapshots/cvsroot' with ''
1331197420.197535: sendbackup: pipespawnv: stdoutfd is 6
1331197420.197678: sendbackup: Spawning /sbin/dump dump 1usf 1048576 - 
/snapshots/cvsroot in pipeline
1331197420.197955: sendbackup: Started backup
1331197420.198348: sendbackup: Started index creator: /sbin/restore -tvf - 
21 | sed -e '
s/^leaf[]*[0-9]*[   ]*\.//
t
/^dir[  ]/ {
s/^dir[ ]*[0-9]*[   ]*\.//
s%$%/%
t
}
d
'
1331197420.451695: sendbackup:  91:  normal(|):   DUMP: Only level 0 dumps are 
allowed on a subdirectory
1331197420.452658: sendbackup:  91:  normal(|):   DUMP: The ENTIRE dump is 
aborted.
1331197420.473535: sendbackup: Index created successfully
1331197420.474460: sendbackup: critical (fatal): error [dump (31209) /sbin/dump 
returned 1]
/usr/lib/amanda/libamanda-2.6.1p2.so(+0x22ab7)[0x7f79f0799ab7]
/lib/libglib-2.0.so.0(g_logv+0x1a7)[0x7f79efa0bd27]
/lib/libglib-2.0.so.0(g_log+0x83)[0x7f79efa0c103]
/usr/lib/amanda/sendbackup(parse_backup_messages+0x25a)[0x4046ea]
/usr/lib/amanda/sendbackup(main+0x11c7)[0x4058d7]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f79ef035c8d]
/usr/lib/amanda/sendbackup[0x403519]
1331086195.919951: sendbackup: pid 19369 ruid 34 euid 34 version 2.6.1p2: start 
at Wed Mar  7 02:09:55 2012
1331086195.920038: sendbackup: Version 2.6.1p2
1331086195.935324: sendbackup: pid 19369 ruid 34 euid 34 version 2.6.1p2: 
rename at Wed Mar  7 02:09:55 2012
1331086195.964518: sendbackup:   Parsed request as: program `DUMP'
1331086195.964542: sendbackup:  disk `/snapshots/cvsroot'
1331086195.964552: sendbackup:  device `/snapshots/cvsroot'
1331086195.964560: sendbackup:  level 0
1331086195.964568: sendbackup:  since NODATE
1331086195.964576: sendbackup:  options `'
1331086195.964777: sendbackup: start: 
vimes.amazing-internet.net:/snapshots/cvsroot lev 0
1331086195.964844: sendbackup: pipespawnv: stdoutfd is 50
1331086195.964912: sendbackup: Spawning /bin/gzip /bin/gzip --fast in pipeline
1331086195.965296: sendbackup: dump: pid 19371: /bin/gzip1331086195.965354: 
sendbackup:  --fast1331086195.965362: sendbackup: 
1331086195.976703: sendbackup: dumping device 
'/dev/mapper/vg_stor-lv_cvsroot_bak' with 'xfs'
1331086195.977965: sendbackup: pipespawnv: stdoutfd is 6
1331086195.978132: sendbackup: Spawning /usr/lib/amanda/rundump 
/usr/lib/amanda/rundump DailySet2 xfsdump -F -l 0 - 
/dev/mapper/vg_stor-lv_cvsroot_bak in pipeline
1331086195.978420: sendbackup: Started backup
1331086195.978740: sendbackup: Started index creator: /sbin/xfsrestore -t -v 
silent - 2/dev/null | sed -e 's/^/\//'
1331086196.135877: sendbackup:  97:  normal(|): xfsdump: using file dump 
(drive_simple) strategy
1331086196.136924: sendbackup:  97:  normal(|): xfsdump: version 3.0.4 (dump 
format 3.0) - Running single-threaded
1331086196.252145: sendbackup:  97:  normal(|): xfsdump: level 0 dump of 
vimes:/snapshots/cvsroot
1331086196.253502: sendbackup:  97:  normal(|): xfsdump: dump date: Wed Mar  7 
02:09:56 2012
1331086196.254438: sendbackup:  97:  normal(|): xfsdump

Bug#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

close
thanks

Hi Bdale,

I think this bug can be closed. I've just checked last nights run and it all 
seems well. xfsdump is now being called on the partitions I expect it to be 
called on. Really not sure why it went bananas for a few days there but thanks 
for your help anyway and big thanks for continuing to package amanda. :-).

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

# trying again...
close 661128
thanks

-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 






signature.asc
Description: OpenPGP digital signature

Bug#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

Package: amanda-client
Version: 1:2.6.1p2-3
Severity: important


I've just upgraded one of our servers, an Amanda backup client from ETCH to
SQUEEZE. The Amanda server is already running Squeeze. The dumps on the client
are now being done using dump rather than xfsdump. They were working with
xfsdump on ETCH prior to the upgrade. I have another Amanda client which
continues to work as expected.

My backup procedure is to freeze the XFS partition, take an LVM snapshot, 
unfreeze, then mount the LVM snapshot and take the backup from the snapshot.

My disklist entries on the server look like:

vimes.amazing-internet.net /snapshots/cvsroot comp-user

nakor.amazing-internet.net /snapshots/mail comp-user

where VIMES is the one running dump incorrectly onm Squeeze  and NAKOR
correctly uses xfsdump on Etch.

Partition info:

/dev/mapper/vg_stor-lv_cvsroot_bak on /snapshots/cvsroot type xfs (ro,nouuid)

/dev/mapper/vg_stor-lv_mailstor_bak on /snapshots/mail type xfs (ro,nouuid)

According to all the docs, Amanda's rundump should detect the parition type and
automatically run xfsdump. Not sure why it's not doing that. It certainly was
prior to the upgrade.

When the dumps are actually running, I'm getting things like the following:

   vimes.amazing-internet.net /snapshots/cvsrootlev 1  FAILED [dump (24845) 
/sbin/dump returned 1]


/--  vimes.amazing-internet.net /snapshots/cvsroot lev 1 FAILED [dump (24845) 
/sbin/dump returned 1]
sendbackup: start [vimes.amazing-internet.net:/snapshots/cvsroot level 1]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/sbin/restore -xpGf - ...
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
|   DUMP: Only level 0 dumps are allowed on a subdirectory
|   DUMP: The ENTIRE dump is aborted.
? dump (24845) /sbin/dump returned 1
sendbackup: error [dump (24845) /sbin/dump returned 1]
\


All not very happy.

I'd really appreciate any insight you can offer. Please let me know if you need 
any further information.

Regards,
Ronny Adsetts




-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages amanda-client depends on:
ii  amanda-common 1:2.6.1p2-3Advanced Maryland Automatic Networ
ii  libc6 2.11.3-2   Embedded GNU C Library: Shared lib
ii  libglib2.0-0  2.24.2-1   The GLib library of C routines
ii  libncurses5   5.7+20100313-5 shared libraries for terminal hand
ii  libreadline6  6.1-3  GNU readline and history libraries

amanda-client recommends no packages.

Versions of packages amanda-client suggests:
ii  dump  0.4b43-1   4.4bsd dump and restore for ext2 f
pn  gnuplot   none (no description available)
ii  smbclient 2:3.5.6~dfsg-3squeeze6 command-line SMB/CIFS clients for 

-- 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#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

Bdale Garbee said at 24/02/2012 17:07:
 #part sign=pgpmime
 On Fri, 24 Feb 2012 10:50:54 +, Ronny Adsetts 
 ronny.adse...@amazinginternet.com wrote:
 
 According to all the docs, Amanda's rundump should detect the parition
 type and automatically run xfsdump. Not sure why it's not doing
 that. It certainly was prior to the upgrade.
 
 Do you actually have the xfsdump package installed on the client system
 in question? 

Yes:

$ hostname
vimes
$ dpkg -l xfsdump
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  xfsdump3.0.4  Administrative utilities for the XFS filesys

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#661128: amanda-client: Backup on XFS partiion uses dump rather than xfsdump

[Ronny Adsetts]

Bdale Garbee said at 24/02/2012 18:38:
 
 The rundump program is not where the automatic filesystem type detection
 happens.  It's just a thin wrapper to handle the required priv increase.
 The things that call it give it a command line argument telling it which
 dump program to invoke.  There is an amname_to_fstype() function that
 works out the file system type,  This gets called, for example, from
 client-src/sendsize.c which should log diagnostics like
 
   calculating for device blah with fstype
 
 It would be good to know what the 'fstype' field shows for the
 filesystem(s) in question if you can find that in your logs.  That will
 help me understand whether the problem is that the filesystem type is
 being incorrectly determined, or the wrong program is being called even
 when the filesystem is properly recognized.

Thanks for the detailed explanation.

Looks like it's detecting correctly:

# grep calculating for device /dev/mapper/vg_stor-lv_cvsroot_bak 
/var/log/amanda/client/DailySet2/sendsize.20120224001504.debug
1330050136.418649: sendsize: calculating for device 
/dev/mapper/vg_stor-lv_cvsroot_bak with xfs
1330050205.426683: sendsize: calculating for device 
/dev/mapper/vg_stor-lv_cvsroot_bak with xfs

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: 69 Strathmore Road, Teddington, TW11 8UH
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#428326: spamassassin: undef at Plugin/DCC.pm line 429 started today

[Ronny Adsetts]

Package: spamassassin
Version: 3.2.3-0.volatile1
Followup-For: Bug #428326


Hi,

I just started seeing this error logged overnight and now it appears to
be logged for every email scanned by spamassassin:

Jan 27 09:01:46 allanon spamd[1894]: dcc: dccifd - check skipped:
Connection refused Can't call method print on an undefined value at
/usr/share/perl5/Mail/SpamAssassin/Plugin/DCC.pm line 429. at
/usr/share/perl5/Mail/SpamAssassin/Plugin/DCC.pm line 471.

After (re)starting dccifd the error goes away.

Thanks.

Ronny

-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages spamassassin depends on:
ii  libarchive-tar-perl 1.30-2   Archive::Tar - manipulate tar file
ii  libdigest-sha1-perl 2.11-1   NIST SHA-1 message digest algorith
ii  libhtml-parser-perl 3.55-1+etch1 A collection of modules that parse
ii  libio-zlib-perl 1.04-1   IO:: style interface to Compress::
ii  libnet-dns-perl 0.59-1etch1  Perform DNS queries from a Perl sc
ii  libsocket6-perl 0.19-1   Perl extensions for IPv6
ii  libsys-hostname-long-perl   1.4-1Figure out the long (fully-qualifi
ii  libwww-perl 5.805-1  WWW client/server library for Perl
ii  perl5.8.8-7etch6 Larry Wall's Practical Extraction 

Versions of packages spamassassin recommends:
pn  gccnone(no description available)
ii  gnupg  1.4.6-2   GNU privacy guard - a free PGP rep
pn  libc6-dev  none(no description available)
ii  libmail-spf-query-perl 1:1.999.1-2   query SPF (Sender Policy Framework
ii  libsys-syslog-perl 0.18-1Perl interface to the UNIX syslog(
pn  make   none(no description available)
ii  re2c   0.9.12-2  Tool for generating fast C-based r
ii  spamc  3.2.3-0.volatile1 Client for SpamAssassin spam filte

-- 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#553638: linux-image-2.6.24-etchnhalf.1-amd64: XFS crash takes filesystem offline

[Ronny Adsetts]

Ben Hutchings said at 01/11/2009 18:58:
 On Sun, 2009-11-01 at 18:18 +, Ronny Adsetts wrote:
 [...]
 Please let me know if I can provide any further information.

 I can do limited testing since the server is a production system. I
 could possibly upgrade to a newer kernel from say backports.org if
 that's a good idea.
 
 Bugs in Debian 4.0 'etch' are now unlikely to be fixed, except for
 security vulnerabilities.  Please try installing the security update
 version for the stable release (linux-image-2.6.26-2-amd64, version
 2.6.26-19lenny1).

Thanks for the fast response Ben.

I'd overlooked that this system was still running Etch.

Should I simply be able to install the Lenny kernel without any problems? 
Alternatively there is an linux-image-2.6.26-bpo.2-amd64 (2.6.26-20~bpo40+1) 
package on etch-backports...

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#522283: lilo: Confirm that patch works

[Ronny Adsetts]

Package: lilo
Followup-For: Bug #522283


Hi,

Note: Bug follow up is not sent from the system with a patched lilo
installed. I took version 22.8-7 and applied the patch in this ticket
and built a package backported to Etch.

I can confirm that the patch attached to this bug fixes the ability to
have lilo run correctly on a RAID1 array where the first device in the
array is missing. Without this patch the -H option fails with:

Fatal: Unusual RAID bios device code: 0xFF

Please apply the patch to the Debian package.

Thanks.

Ronny


-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages lilo depends on:
ii  debconf1.5.11etch2   Debian configuration management sy
ii  libc6  2.3.6.ds1-13etch9 GNU C Library: Shared libraries
ii  libdevmapper1.02   2:1.02.08-1   The Linux Kernel Device Mapper use
ii  mbr1.1.9-2   Master Boot Record for IBM-PC comp

lilo recommends no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#553638: linux-image-2.6.24-etchnhalf.1-amd64: XFS crash takes filesystem offline

[Ronny Adsetts]

Package: linux-image-2.6.24-etchnhalf.1-amd64
Version: 2.6.24-6~etchnhalf.8etch3
Severity: normal


Please see the XFS crash trace included below. The summary is:

XFS internal error xfs_trans_cancel at line 1163 of file
fs/xfs/xfs_trans.c

I've not logged this to an existing ticket sice it seems to be a class
of bug rather, a symptom, so I don't feel qualified to make that call.

This happens on a fairly regular basis with a 250GB XFS filesystem which
is one of several logical volumes on a 1.36TB LVM volume group. The
underlying device is an Areca hardware RAID card.

When the fs will go offline is not predicatable but it always happens
during reasonably heavy fs activity. This particular crash happened
while I was doing 'cp -a' on a directory containing about 27GB in 812,714 files 
and 12,833 directories.

Please let me know if I can provide any further information.

I can do limited testing since the server is a production system. I
could possibly upgrade to a newer kernel from say backports.org if
that's a good idea.

Thanks.

Ronny


-- Package-specific info:
** Version:
Linux version 2.6.24-etchnhalf.1-amd64 (Debian 2.6.24-6~etchnhalf.8etch3) 
(da...@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) 
#1 SMP Sat Aug 15 20:38:41 UTC 2009

** Command line:
auto BOOT_IMAGE=Linux ro root=900

** Not tainted

** Kernel log:
Ending XFS recovery on filesystem: dm-10 (logdev: internal)
Filesystem dm-6: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-6
Ending clean XFS mount for filesystem: dm-6
Filesystem dm-16: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-16
Ending clean XFS mount for filesystem: dm-16
Filesystem dm-7: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-7
Ending clean XFS mount for filesystem: dm-7
Filesystem dm-8: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-8
Ending clean XFS mount for filesystem: dm-8
Filesystem dm-17: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-17
Ending clean XFS mount for filesystem: dm-17
Filesystem dm-4: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-4
Ending clean XFS mount for filesystem: dm-4
Filesystem dm-3: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-3
Ending clean XFS mount for filesystem: dm-3
Filesystem dm-15: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-15
Ending clean XFS mount for filesystem: dm-15
Filesystem dm-14: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-14
Ending clean XFS mount for filesystem: dm-14
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: RX
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
lp0: using parport0 (interrupt-driven).
ppdev: user-space parallel port driver
Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
eth0: no IPv6 routers present
Filesystem dm-20: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-20
Starting XFS recovery on filesystem: dm-20 (logdev: internal)
XFS resetting qflags for filesystem dm-20
Ending XFS recovery on filesystem: dm-20 (logdev: internal)
Filesystem dm-23: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-23
Starting XFS recovery on filesystem: dm-23 (logdev: internal)
Ending XFS recovery on filesystem: dm-23 (logdev: internal)
Filesystem dm-26: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-26
Starting XFS recovery on filesystem: dm-26 (logdev: internal)
Ending XFS recovery on filesystem: dm-26 (logdev: internal)
Filesystem dm-29: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-29
XFS resetting qflags for filesystem dm-29
Ending clean XFS mount for filesystem: dm-29
Filesystem dm-32: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-32
Starting XFS recovery on filesystem: dm-32 (logdev: internal)
Ending XFS recovery on filesystem: dm-32 (logdev: internal)
Filesystem dm-35: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-35
Starting XFS recovery on filesystem: dm-35 (logdev: internal)
Ending XFS recovery on filesystem: dm-35 (logdev: internal)
Filesystem dm-38: Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-38
XFS resetting qflags for filesystem dm-38
Ending clean XFS mount for filesystem: dm-38
md: data-check of RAID array md0
md: minimum _guaranteed_  speed: 1000 

Bug#500592: Using pngcrush warns of different versions for png.c and png.h

[Ronny Adsetts]

Kapil Hari Paranjape said at 30/09/2008 01:51:
 
 Here is what is written in the changelog regarding closing #203020
 * debian/patches/pngcrush_relocate_warning: relocated warning
 about different versions to verbose header. Closes: #203020.
 
 The keyword is relocated as opposed to eliminated.
 
 Since this bug does not affect the core functionality of pngcrush, I
 am reducing the severity to minor.
 
 The full story follows.
 
 The Debian binary package makes use of the dynamically loadable
 libpng for a number of reasons. The warning indicates that libpng has
 been upgraded but pngcrush has not been re-compiled.
 
 The upstream author provides a version of pngcrush that uses its own
 version of the png routines and feels that this is a better way to do
 things. However, in order to make it easier for Debian, this -nolib
 version is also provided. Thus, the warning when there is a
 mis-match.
 
 Originally, the warning appeared everytime pngcrush was run which
 was annoying, especially when it was run in cron scripts. Thus the
 warning has been _relocated_ to be shown only when pngcrush is run in
 verbose mode or when you explicitly ask for version info.
 
 Hope this clarifies matters,

Hi Kapil,

Thanks for the clarification. It appears the change was made for 1.6.4-4 
whereas etch has 1.6.4-3 which explains why I see the warning every time the 
program is run. Very annoying but as you say does not affect the core 
functionality of pngcrush.

I guess this bug can be merged with 203020 and closed.

Apologies for the noise.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#500592: Using pngcrush warns of different versions for png.c and png.h

[Ronny Adsetts]

Package: pngcrush
Version: 1.6.4-3
Severity: normal


$ pngcrush -version
Warning: versions are different between png.h and png.c
  png.h version: 1.2.13
  png.c version: 1.2.15beta5

 pngcrush 1.6.4, uses libpng 1.2.13 and zlib 1.2.3
 Check http://pmt.sf.net/
 for the most recent version.

I note this was previously reported in archived bugs #203020 and
#289061.

Thanks.

Ronny

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages pngcrush depends on:
ii  libc6  2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii  libpng12-0 1.2.15~beta5-1PNG library - runtime
ii  zlib1g 1:1.2.3-13compression library - runtime

pngcrush recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#420391: clamav-daemon: Update of problem with 0.94

[Ronny Adsetts]

Stephen Gran said at 06/09/2008 20:26:
 This one time, at band camp, Ronny Adsetts said:

 Quick update on this problem with the latest clamav to keep it on the
 radar:

 $ uname -a
 Linux allanon 2.6.24-etchnhalf.1-amd64 #1 SMP Mon Jul 21 10:36:02 UTC
 2008 x86_64 GNU/Linux

 $ ps Hu -C clamd
 USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
 clamav   30091  0.0 11.1 264900 230540 ?   Ssl  Sep05   0:14
 /usr/sbin/clamd
 clamav   30091  0.0 11.1 264900 230540 ?   Ssl  18:57   0:00
 /usr/sbin/clamd

 So it's still there. Let me know if there's anything I can do to help.
 
[... description of memory fragmentation on database reloads snipped ...]
 
 If my understanding is correct, I'm afraid this is only going to get
 worse as the databases get bigger.  It can get more efficient, but the
 underlying problem seems like it is likely to stay the same.

That's my understanding of the problem too though I would hate to have to add 
more memory to the system just so that clamav can run. There are a couple of 
bugs in the clamav bug tracker that may be of relevance.

See this one that talks about the fragmentation (marked invalid):

https://wwws.clamav.net/bugzilla/show_bug.cgi?id=736

This one talks about the ref counting on the in-memory DB preventing the freed 
memory from being reused (or something along those lines):

https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1028

This latter bug has a fix that should see the light of day in 0.95 from the 
ticket comments. If I read the ticket right, this fix should prevent the memory 
usage from escalating to the extent it does now (my main live system currently 
shows RSS at 260688).

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#420391: clamav-daemon: Update of problem with 0.94

[Ronny Adsetts]

Package: clamav-daemon
Version: 0.94.dfsg-1~volatile1
Followup-For: Bug #420391


Hi Stephen,

Quick update on this problem with the latest clamav to keep it on the
radar:

$ uname -a
Linux allanon 2.6.24-etchnhalf.1-amd64 #1 SMP Mon Jul 21 10:36:02 UTC
2008 x86_64 GNU/Linux

$ ps Hu -C clamd
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   30091  0.0 11.1 264900 230540 ?   Ssl  Sep05   0:14
/usr/sbin/clamd
clamav   30091  0.0 11.1 264900 230540 ?   Ssl  18:57   0:00
/usr/sbin/clamd

So it's still there. Let me know if there's anything I can do to help.

Ronny

-- Package-specific info:
--- configuration ---
/etc/clamav/clamd.conf: clamd directives
--
LogFile = /var/log/clamav/clamav.log
LogFileUnlock = no
LogFileMaxSize = 0
LogTime = yes
LogClean = no
LogVerbose = no
LogSyslog = no
LogFacility = LOG_LOCAL6
PidFile = /var/run/clamav/clamd.pid
TemporaryDirectory = /tmp
ScanPE = yes
ScanELF = yes
DetectBrokenExecutables = no
ScanMail = yes
MailFollowURLs = no
ScanPartialMessages = no
PhishingSignatures = yes
PhishingScanURLs = yes
PhishingAlwaysBlockCloak = no
PhishingAlwaysBlockSSLMismatch = no
HeuristicScanPrecedence = no
DetectPUA = no
ExcludePUA not set
IncludePUA not set
StructuredDataDetection = no
StructuredMinCreditCardCount = 3
StructuredMinSSNCount = 3
StructuredSSNFormatNormal = yes
StructuredSSNFormatStripped = no
AlgorithmicDetection = yes
ScanHTML = yes
ScanOLE2 = yes
ScanPDF = no
ScanArchive = yes
MaxScanSize = 104857600
MaxFileSize = 26214400
MaxRecursion = 16
MaxFiles = 1
ArchiveLimitMemoryUsage = no
ArchiveBlockEncrypted = no
DatabaseDirectory = /var/lib/clamav
TCPAddr not set
TCPSocket not set
LocalSocket = /var/run/clamav/clamd.ctl
MaxConnectionQueueLength = 15
StreamMaxLength = 10485760
StreamMinPort = 1024
StreamMaxPort = 2048
MaxThreads = 12
ReadTimeout = 180
IdleTimeout = 30
MaxDirectoryRecursion = 15
ExcludePath not set
FollowDirectorySymlinks = no
FollowFileSymlinks = no
ExitOnOOM = no
Foreground = no
Debug = no
LeaveTemporaryFiles = no
FixStaleSocket = yes
User = clamav
AllowSupplementaryGroups = yes
SelfCheck = 3600
VirusEvent not set
ClamukoScanOnAccess not set
ClamukoScanOnOpen not set
ClamukoScanOnClose not set
ClamukoScanOnExec not set
ClamukoIncludePath not set
ClamukoExcludePath not set
ClamukoMaxFileSize = 5242880
DevACOnly not set
DevACDepth not set

/etc/clamav/freshclam.conf: freshclam directives
--
LogFileMaxSize = 0
LogTime = no
LogVerbose = no
LogSyslog = no
LogFacility = LOG_LOCAL6
PidFile = /var/run/clamav/freshclam.pid
DatabaseDirectory = /var/lib/clamav/
Foreground = no
Debug = no
AllowSupplementaryGroups = no
DatabaseOwner = clamav
Checks = 96
UpdateLogFile = /var/log/clamav/freshclam.log
DNSDatabaseInfo = current.cvd.clamav.net
DatabaseMirror = db.local.clamav.net
DatabaseMirror = database.clamav.net
DatabaseMirror = db.uk.clamav.net
MaxAttempts = 5
ScriptedUpdates = yes
CompressLocalDatabase = no
HTTPProxyServer not set
HTTPProxyPort not set
HTTPProxyUsername not set
HTTPProxyPassword not set
HTTPUserAgent not set
NotifyClamd not set
OnUpdateExecute not set
OnErrorExecute not set
OnOutdatedExecute not set
LocalIPAddress not set
ConnectTimeout = 30
ReceiveTimeout = 30

Engine and signature databases
--
Engine version: 0.94
Database directory: /var/lib/clamav/
main db: Format: .cld, Version: 48, Build time: Thu Sep  4 19:51:34 2008
daily db: Format: .cld, Version: 8174, Build time: Sat Sep  6 13:25:56 2008

--- data dir ---
total 38440
-rw-r--r-- 1 clamav clamav  1079296 2008-09-06 13:34 daily.cld
-rw-r--r-- 1 clamav clamav 38275584 2008-09-04 21:41 main.cld
-rw--- 1 clamav clamav  364 2008-09-06 18:49 mirrors.dat

-- 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.24-etchnhalf.1-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages clamav-daemon depends on:
ii  clamav-base0.94.dfsg-1~volatile1 anti-virus utility for Unix - base
ii  clamav-freshclam [ 0.94.dfsg-1~volatile1 anti-virus utility for Unix - viru
ii  libc6  2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii  libclamav5 0.94.dfsg-1~volatile1 anti-virus utility for Unix - libr
ii  lsb-base   3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii  ucf2.0020Update Configuration File: preserv
ii  zlib1g 1:1.2.3-13compression library - runtime

clamav-daemon recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#420391: This is still a problem, reopening

[Ronny Adsetts]

Stephen Gran said at 06/06/2008 10:54:


$ ls -ltR /var/lib/clamav/
/var/lib/clamav/:
total 17352
-rw--- 1 clamav clamav  364 2008-06-06 08:25 mirrors.dat
-rw-r--r-- 1 clamav clamav  4703744 2008-06-06 03:25 daily.cld
-rw-r--r-- 1 clamav clamav 13050207 2008-05-30 20:18 main.cvd


Please remove everything except these three files.  The others are
dupicates that may be unnecessarily bloating the memory usage.


Hi Stephen,

After a few days of running, the current memory usage is:

$ ps Hu -C clamd
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   18045  0.0  9.1 222656 187600 ?   Ssl  Jun06   1:08 /usr/sbin/clamd
clamav   18045  0.1  9.1 222656 187600 ?   Ssl  11:40   0:00 /usr/sbin/clamd

This is about 3x the starting memory. Whilst it's better than it was, it's 
still a big chunk of memory.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#420391: This is still a problem, reopening

[Ronny Adsetts]

Stephen Gran said at 05/06/2008 23:28:

This one time, at band camp, Ronny Adsetts said:
This continues to be a problem with etch-volatile though at the moment it 
does appear to be a little better:


$ ps Hu -C clamd
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28153  0.0  9.9 247064 204272 ?   Ssl  May30   2:40 
/usr/sbin/clamd
clamav   28153  0.3  9.9 247064 204272 ?   Ssl  19:06   0:00 
/usr/sbin/clamd


Do you have any 3rd party signatures loaded?  Or just the two from the
clamav team?  I do see what seems like too much memory usage, but not
that high, with just the two databases from clamav.


This is the standard set of signatures:

$ ls -ltR /var/lib/clamav/
/var/lib/clamav/:
total 17352
-rw--- 1 clamav clamav  364 2008-06-06 08:25 mirrors.dat
-rw-r--r-- 1 clamav clamav  4703744 2008-06-06 03:25 daily.cld
-rw-r--r-- 1 clamav clamav 13050207 2008-05-30 20:18 main.cvd
drwxr-xr-x 2 clamav clamav  124 2008-05-30 18:15 main.inc
drwxr-xr-x 2 clamav clamav 4096 2008-05-30 18:15 daily.inc

/var/lib/clamav/main.inc:
total 27568
-rw-r--r-- 1 clamav clamav 4815 2008-04-06 20:25 main.fp
-rw-r--r-- 1 clamav clamav 14934069 2008-04-06 20:25 main.ndb
-rw-r--r-- 1 clamav clamav  4733425 2008-04-06 20:25 main.db
-rw-r--r-- 1 clamav clamav   652769 2008-04-06 20:25 main.hdb
-rw-r--r-- 1 clamav clamav  7864180 2008-04-06 20:25 main.mdb
-rw-r--r-- 1 clamav clamav  318 2008-04-06 20:25 main.info
-rw-r--r-- 1 clamav clamav  217 2007-07-20 18:27 main.zmd
-rw-r--r-- 1 clamav clamav17992 2007-07-20 18:27 COPYING

/var/lib/clamav/daily.inc:
total 4316
-rw-r--r-- 1 clamav clamav 668 2008-05-30 18:03 daily.info
-rw-r--r-- 1 clamav clamav 3993378 2008-05-30 18:03 daily.mdb
-rw-r--r-- 1 clamav clamav  271744 2008-05-30 18:03 daily.ndb
-rw-r--r-- 1 clamav clamav7478 2008-05-28 22:25 daily.ndu
-rw-r--r-- 1 clamav clamav7164 2008-05-27 22:25 daily.hdb
-rw-r--r-- 1 clamav clamav   38992 2008-05-27 10:25 daily.mdu
-rw-r--r-- 1 clamav clamav5232 2008-05-21 08:25 daily.fp
-rw-r--r-- 1 clamav clamav 131 2008-05-21 01:25 daily.ign
-rw-r--r-- 1 clamav clamav5788 2008-05-13 12:25 daily.ftm
-rw-r--r-- 1 clamav clamav1572 2008-05-07 20:25 daily.wdb
-rw-r--r-- 1 clamav clamav 142 2008-04-28 19:25 daily.cfg
-rw-r--r-- 1 clamav clamav   26014 2008-04-06 22:26 daily.db
-rw-r--r-- 1 clamav clamav3218 2008-03-26 23:28 daily.pdb
-rw-r--r-- 1 clamav clamav1224 2008-02-05 16:25 daily.hdu
-rw-r--r-- 1 clamav clamav2922 2007-09-03 19:25 daily.zmd
-rw-r--r-- 1 clamav clamav   17992 2007-06-03 14:43 COPYING

Let me know if you want any more info.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#420391: This is still a problem, reopening

[Ronny Adsetts]

Stephen Gran said at 06/06/2008 10:54:

This one time, at band camp, Ronny Adsetts said:


$ ls -ltR /var/lib/clamav/
/var/lib/clamav/:
total 17352
-rw--- 1 clamav clamav  364 2008-06-06 08:25 mirrors.dat
-rw-r--r-- 1 clamav clamav  4703744 2008-06-06 03:25 daily.cld
-rw-r--r-- 1 clamav clamav 13050207 2008-05-30 20:18 main.cvd


Please remove everything except these three files.  The others are
dupicates that may be unnecessarily bloating the memory usage.


OK, deleted and clamd restarted. Current memory usage is:

$ ps Hu -C clamd
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   18045  0.0  3.1  81068 64832 ?Ssl  10:57   0:00 /usr/sbin/clamd
clamav   18045  0.2  3.1  81068 64832 ?Ssl  10:57   0:00 /usr/sbin/clamd

I'll report back in a few days with the usage to see whether it still bloats.

Thanks.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#420391: This is still a problem, reopening

[Ronny Adsetts]

package clamav-daemon
found 420391 0.93~dfsg-volatile1
thanks 


This continues to be a problem with etch-volatile though at the moment it does 
appear to be a little better:

$ ps Hu -C clamd
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   28153  0.0  9.9 247064 204272 ?   Ssl  May30   2:40 /usr/sbin/clamd
clamav   28153  0.3  9.9 247064 204272 ?   Ssl  19:06   0:00 /usr/sbin/clamd

Thanks.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 









signature.asc
Description: OpenPGP digital signature

Bug#478686: amanda-client: amrecover trims filenames resulting in inability to to directly restore

[Ronny Adsetts]

Package: amanda-client
Version: 1:2.5.1p1-2.1
Severity: important


I'm having a problem with amrecover that is best described by example:

First, I'm in amrecover and have navigated in to the disk
/snapshots/mail: 

amrecover pwd
/snapshots/mail/ronny/Maildir/.System.PHP errors

Then a listing:

amrecover ls
2008-04-30-00-05-02 ildirfolder
2008-04-30-00-05-02 vecot.index.log.2
2008-04-30-00-05-02 vecot.index.log
2008-04-30-00-05-02 vecot.index.cache
2008-04-30-00-05-02 vecot.index
2008-04-30-00-05-02 vecot-uidlist
2008-04-30-00-05-02 vecot-keywords
2008-04-30-00-05-02 r/

Note that the file/folder names have been trimmed. Now I can 'cd' in to a 
folder using the right folder name but an 'add' to do a restore does not work:

amrecover cd cur
/snapshots/mail/ronny/Maildir/.System.PHP errors/cur
amrecover cd ..
/snapshots/mail/ronny/Maildir/.System.PHP errors
amrecover add cur
File cur doesn't exist in directory
amrecover add r
File r doesn't exist in directory

I only see this behaviour where I have a space in the path I'm currently
in.

This obviously makes partial restores quite painful.

This was not a problem on sarge, I only saw on once I'd had to do a
restore on a computer that had been upgraded to etch. Backup server is
etch. I can't test our one sarge computer I'm afraid as I get an error
on trying to set the disk: 501- ERROR: Split dumps not supported with
old version of amrecover.

Let me know if there's any other information I can provide.

Thanks.

Ronny


-- 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_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages amanda-client depends on:
ii  amanda-common  1:2.5.1p1-2.1 Advanced Maryland Automatic Networ
ii  libc6  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  libncurses55.5-5 Shared libraries for terminal hand
ii  libreadline5   5.2-2 GNU readline and history libraries

amanda-client recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#420391: This is still a problem, reopening

[Ronny Adsetts]

This didn't make it to the bug last time so trying again now the bug is 
unarchived...

I'm still seeing this problem with etch-volatile so re-opening the bug:

$ ps Hu -C clamd
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
clamav   26083  0.0 12.5 303976 257860 ?   Ssl  Apr18   2:32 /usr/sbin/clamd
clamav   26083  0.0 12.5 303976 257860 ?   Ssl  15:50   0:00 /usr/sbin/clamd

That's a shed-load of RAM. Other than restarting clamd periodically, is there 
no end in sight for this? The upstream ticket is resolved/invalid...:
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=736

Thanks.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 







signature.asc
Description: OpenPGP digital signature

Bug#299701: [Logcheck-devel] Moving a rule to its package ? [Fwd: Suggestion : include /etc/logcheck/ignore.d.server/sympa in sympa package]

[Ronny Adsetts]

martin f krafft said at 17/04/2008 08:14:

also sprach Olivier Berger [EMAIL PROTECTED] [2008.04.16.1147 +0200]:

Should the rules be included in the sympa package, to be adapted to
updates of the program, or be kept in logcheck-database (for cases of
manual installations of sympa ?).


I think it makes more sense to have it distributed by sympa.


Personally I'd prefer it to be distributed with logcheck. When you have a 
centralised log server running logcheck, it's rather painful trying to get 
rules set up when packages ship their own logcheck rules.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#299701: [Logcheck-devel] Bug#299701: Moving a rule to its package ? [Fwd: Suggestion : include /etc/logcheck/ignore.d.server/sympa in sympa package]

[Ronny Adsetts]

martin f krafft said at 17/04/2008 09:34:

also sprach Ronny Adsetts [EMAIL PROTECTED] [2008.04.17.1010 +0200]:

Personally I'd prefer it to be distributed with logcheck. When you
have a centralised log server running logcheck, it's rather
painful trying to get rules set up when packages ship their own
logcheck rules.


This is not what logcheck was designed for.


Seems like a sensible way to use it to me. :-).


Anyway, I don't want to come across as dictating what can and cannot
be done.

Ronny, if you are using logcheck extensively, maybe you could help
out a bit with the packaging?


I dunno about extensively, but sure. Wanna point me in the direction of stuff 
that needs doing? I'll have a look at the outstanding bugs later today.


The basic rule remains: those who do get to decide how to do it. :)


Indeed.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#467136: Bug#348046: TLS error occurs on Sarge too

[Ronny Adsetts]

Marc Haber said at 23/02/2008 10:18:

On Mon, Oct 16, 2006 at 10:32:26AM +0100, Ronny Adsetts wrote:

This error is occurring with 4.50-8sarge2 on Sarge too. Judging by my
munin graphs on both sending and receiving side, there's no entropy on
the sending side. I noticed this error yesterday when there was
testing on a client's site that resulted in a couple of hundred emails
being sent to us in rapid succession.


Do you still see this on etch or lenny?


Hi Marc,

I've not yet upgraded the two mail servers in question to etch, however looking 
in the one mail server we do have on etch shows the following single log entry 
for the default exim log period (10 days or so):

/var/log/exim4/mainlog.8.gz:2008-02-15 17:00:43 1JQ24M-0005wR-EX TLS error on 
connection to mailgate.mylor.com [80.176.71.10] (gnutls_handshake): The Diffie 
Hellman prime sent by the server is not acceptable (not long enough).

/var/log/exim4/mainlog.8.gz:2008-02-15 17:00:43 1JQ24M-0005wR-EX TLS session 
failure: delivering unencrypted to mailgate.mylor.com [80.176.71.10] (not in 
hosts_require_tls)

/var/log/exim4/mainlog.8.gz:2008-02-15 17:00:52 1JQ24M-0005wR-EX = [EMAIL 
PROTECTED] R=dnslookup T=remote_smtp H=mailgate.mylor.com [80.176.71.10]

Whilst the error message above is not exactly the same as in my original 
report, it's close enough that it *may* be the same error with a more specific 
error message.

Let me know if there's anything else I can do.

Thanks for your continued hard work on the exim package. :-).

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#467136: Bug#348046: TLS error occurs on Sarge too

[Ronny Adsetts]

Marc Haber said at 23/02/2008 11:12:

On Sat, Feb 23, 2008 at 11:10:27AM +, Ronny Adsetts wrote:

Marc Haber said at 23/02/2008 10:18:

On Mon, Oct 16, 2006 at 10:32:26AM +0100, Ronny Adsetts wrote:

This error is occurring with 4.50-8sarge2 on Sarge too. Judging by my
munin graphs on both sending and receiving side, there's no entropy on
the sending side. I noticed this error yesterday when there was
testing on a client's site that resulted in a couple of hundred emails
being sent to us in rapid succession.


Do you still see this on etch or lenny?


I've not yet upgraded the two mail servers in question to etch,


It would be a good idea to do so, I won't do any more debugging on
sarge.


Understood. At least one of the boxes will get upgraded this weekend.

/var/log/exim4/mainlog.8.gz:2008-02-15 17:00:43 1JQ24M-0005wR-EX TLS error 
on connection to mailgate.mylor.com [80.176.71.10] (gnutls_handshake): The 
Diffie Hellman prime sent by the server is not acceptable (not long enough).


That looks like an issue on the remote side.


It does indeed.

Whilst the error message above is not exactly the same as in my original 
report, it's close enough that it *may* be the same error with a more 
specific error message.


nack.


In that case, unless you receive contrary info, I'd suggest marking as fixed in 
the Etch version of exim. I'll try to test by firing of a few hundred emails 
from one box to the other once I have two exim servers on Etch and reopen if 
the problem shows up again.

Thanks.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#420391: Still large memory footprint

[Ronny Adsetts]

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

$ dpkg-query -W clamav
clamav  0.92~dfsg-1~volatile2

$ uptime
11:47:08 up 3 days, 20:10,  1 user,  load average: 0.04, 0.06, 0.08

$ uname -a
Linux allanon 2.6.18-6-amd64 #1 SMP Wed Jan 23 06:27:23 UTC 2008 x86_64 
GNU/Linux

Hope this helps.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 





signature.asc
Description: OpenPGP digital signature

Bug#440077: xl2tpd: Please provide a backport for etch

[Ronny Adsetts]

Package: xl2tpd
Version: 1.1.11.dfsg.1-2
Severity: wishlist


Thank you very much for packaging Xelerences fork of l2tpd. I would
appreciate it very much as would others I'm sure if you would provide a
backport for etch of xl2tpd at backports.org.

Thank you for your time.

Ronny

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-11-em64t-p4-smp
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431243: nscd error/warning on no more memory for database 'hosts'

[Ronny Adsetts]

Hi,

I see this error too:

nscd: 10645 no more memory for database 'hosts'

Anything I can do to help debug and find a solution?

The computer exhibiting the error was running fine with no errors doing ldap 
only. Once I'd moved our mail services on to it (exim4, spamassassin, clamav, 
dovecot, mysql, ldap), I started getting the log message. Server is not busy 
load wise - delivers about 7000 emails a day to a mixture of forwards and 
maildir mail boxes.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: Finally got a backtrace on this crash

[Ronny Adsetts]

Marc Haber said at 06/06/2007 15:44:
 
 I apologize for taking so much time to react. Thank you very much for
 taking so much time to reproduce this issue.

Hi Marc.

No worries, it's the least I can do.

 On Sun, May 13, 2007 at 06:34:20PM +0100, Ronny Adsetts wrote:
 Core was generated by `/usr/sbin/exim4 -bd -q30m -oX 587:465:25 -oP 
 /var/run/ex.
 Program terminated with signal 11, Segmentation fault.

 [...]

 #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
 120 gnutls_num.c: No such file or directory.
 in gnutls_num.c
 (gdb) bt
 #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
 #1  0x2ba3e841bfc9 in _gnutls_proc_rsa_client_kx (session=0x629e10,
 data=0x0, _data_size=61) at auth_rsa.c:213
 #2  0x2ba3e84171e9 in _gnutls_recv_client_kx_message (session=0x629e10)
 at gnutls_kx.c:333
 
 This looks like a GnuTLS issue to me.

Yeah, me too.

 Please let me know if you want any more information.
 
 ldd /usr/sbin/exim4 | grep gnutls, and if possible, the exact Debian
 version of the libgnutls package which contains the library your exim4
 binbary is linked to.

$ ldd /usr/sbin/exim4 | grep gnutls
libgnutls.so.11 = /usr/lib/libgnutls.so.11 (0x002a96b96000)

$ dpkg-query -W 'libgnutls11'
libgnutls11 1.0.16-13.2sarge2

 I'll then clone and reassign the bug to the appropriate gnutls package.

Thanks.

From what I discovered when googling around, the problem *may* be limited to 
amd64.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: Finally got a backtrace on this crash

[Ronny Adsetts]

Marc Haber said at 06/06/2007 16:38:
 On Wed, Jun 06, 2007 at 04:33:30PM +0100, Ronny Adsetts wrote:
 $ ldd /usr/sbin/exim4 | grep gnutls
 libgnutls.so.11 = /usr/lib/libgnutls.so.11 (0x002a96b96000)

 $ dpkg-query -W 'libgnutls11'
 libgnutls11 1.0.16-13.2sarge2

 I'll then clone and reassign the bug to the appropriate gnutls package.
 Thanks.

 From what I discovered when googling around, the problem *may* be
 limited to amd64.
 
 Is there any time frame for you updating to etch? I rather doubt that
 the gnutls people would be willing to debug on sarge's libraries.

I would guess in the next couple of months. Depends on other workload really.

If I see the crash again once I'm on etch, I'll update the ticket. Unless 
there's an obvious error that jumps out at the gnutls devs from the backtrace, 
I can't see where else to go.

Thanks for all your help on this.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: Finally got a backtrace on this crash

[Ronny Adsetts]

Marc Haber said at 06/06/2007 16:51:
 On Wed, Jun 06, 2007 at 04:45:40PM +0100, Ronny Adsetts wrote:
 If I see the crash again once I'm on etch, I'll update the ticket.
 Unless there's an obvious error that jumps out at the gnutls devs from
 the backtrace, I can't see where else to go.
 
 Can I mark ist as fixed in 4.63-17, which is the version we released
 with etch, in the mean time? If you find the bug to happen with etch
 as well, send found #412886 4.63-17 to [EMAIL PROTECTED], and the bug
 will be marked correctly.
 
 That way, I'll get it out of my bug report list for the time being.
 
 Is that acceptable for you?

That sounds fine to me. Go for it.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: RFH gnutls related crash of exim4 on x86_64 (Bug#412886)

[Ronny Adsetts]

Simon Josefsson said at 15/05/2007 21:53:
 On 15 maj 2007, at 22.24, Ronny Adsetts wrote:
 Simon Josefsson said at 15/05/2007 20:53:
 [snip lots of helpful debug data]

 Please let me know if you want any more information.

 If you can reproduce the crash in gdb, try getting a backtrace using 'bt
 full', and invoke 'up' until you are in the _gnutls_recv_handshake stack
 frame, then 'p recv_type'.  If it is indeed
 GNUTLS_HANDSHAKE_CLIENT_HELLO or GNUTLS_HANDSHAKE_SERVER_HELLO then I
 think we have diagnosed the cause.
 [...]

 Simon, thanks for your help so far.

 Assuming the delivery starts again, it stopped this morning, it'll
 keep trying every hour for about three days...

 Unless you know if it's possible to take a tcpdump and recreate the
 transaction?
 
 Yes, do try to get a tcpdump trace of the session.  It may not be
 possible to recreate the transaction with live code, but at least we can
 look at what the other end is sending, and especially if it is sending a
 client hello again when GnuTLS expects something else.

I have tcpdumps from a couple of earlier crashing sessions. They're attached to 
the Cc'd Debian bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412886;msg=15;filename=20070228_190841_crasher.pcap;att=1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412886;msg=20;filename=20070228_200842_crasher.pcap;att=1

Hopefully that'll be helpful.

NB. My posts are being rejected from [EMAIL PROTECTED] so I assume the list is 
subscriber only

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: RFH gnutls related crash of exim4 on x86_64 (Bug#412886)

[Ronny Adsetts]

Simon Josefsson said at 15/05/2007 20:53:
[snip lots of helpful debug data]

 Please let me know if you want any more information.
 
 If you can reproduce the crash in gdb, try getting a backtrace using 'bt
 full', and invoke 'up' until you are in the _gnutls_recv_handshake stack
 frame, then 'p recv_type'.  If it is indeed
 GNUTLS_HANDSHAKE_CLIENT_HELLO or GNUTLS_HANDSHAKE_SERVER_HELLO then I
 think we have diagnosed the cause.
[...]

Simon, thanks for your help so far.

Assuming the delivery starts again, it stopped this morning, it'll keep trying 
every hour for about three days...

Unless you know if it's possible to take a tcpdump and recreate the transaction?

 Any chance to contact the remote host to find out what software it is
 using?

I tried but didn't get very far. Maybe I'll give it another go.

If I manage to get any more data as outlined above, I'll reply to the thread.

Thanks again.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: Finally got a backtrace on this crash

[Ronny Adsetts]

Hi Marc/Andreas,

I've finally managed to get a core file on this segfault:

---
$ sudo gdb /usr/sbin/exim4 core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as x86_64-linux...Using host libthread_db library /l.

Core was generated by `/usr/sbin/exim4 -bd -q30m -oX 587:465:25 -oP /var/run/ex.
Program terminated with signal 11, Segmentation fault.

[...]

#0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
120 gnutls_num.c: No such file or directory.
in gnutls_num.c
(gdb) bt
#0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
#1  0x2ba3e841bfc9 in _gnutls_proc_rsa_client_kx (session=0x629e10,
data=0x0, _data_size=61) at auth_rsa.c:213
#2  0x2ba3e84171e9 in _gnutls_recv_client_kx_message (session=0x629e10)
at gnutls_kx.c:333
#3  0x2ba3e8412c72 in _gnutls_handshake_server (session=0x629e10)
at gnutls_handshake.c:2259
#4  0x2ba3e841236b in gnutls_handshake (session=0x629e10)
at gnutls_handshake.c:1908
#5  0x004604a7 in tls_server_start (require_ciphers=0x0)
at tls-gnu.c:838
#6  0x00459339 in smtp_setup_msg () at smtp_in.c:3212
#7  0x00418fc3 in handle_smtp_call (listen_sockets=0x5e3cd0,
listen_socket_count=6, accept_socket=0, accepted=0x0) at daemon.c:495
#8  0x0041a55c in daemon_go () at daemon.c:1815
#9  0x0042848b in main (argc=7, cargv=0x0) at exim.c:3922
---

Please let me know if you want any more information.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 03/04/2007 12:13:
 On Wed, Mar 28, 2007 at 07:00:43PM +0100, Ronny Adsetts wrote:
[...]

 Do you have any pointers on getting exim4 to dump core without a
 kernel upgrade? I can do it as a last resort with a backports.org
 kernel if needed but would prefer to avoid this.
 
 Unfortunately, I have not found any relief short of replacing the exim
 binary with an suid wrapper which sets the ulimits appropriately and
 then hands over control to exim as root.

Hi Marc.

Thanks for the info. At the moment, I can't get the remote system administrator 
to respond to my emails so can't get the segfault recurring.

Should I get it crashing again, I'll upgrade to the backports kernel. That 
seems to be the path of least resistance.

Suggest we mark as unreproducible for the moment?

NB: A google turned up this which may be related:
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20060911/msg00012.html

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 26/03/2007 21:58:
 
 Asking on exim-user yielded a pointer to core(5), which in turn
 pointed me to proc(5). Additionally, Jakob suggeested setting
 /proc/sys/fs/suid_dumpable to 1 or (safer) 2? to allow exim as a suid
 binary to dump core.
 
 The core file is going to be put in exim's spool directory.

Thanks - it helps me out some but man 5 proc which I grabbed from unstable 
says: /proc/sys/fs/suid_dumpable (since Linux 2.6.13) which gives me a 
problem since I'm on sarge with a 2.6.8 kernel.

Do you have any pointers on getting exim4 to dump core without a kernel 
upgrade? I can do it as a last resort with a backports.org kernel if needed but 
would prefer to avoid this.

Thanks again.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 19/03/2007 11:15:
 
 On Mon, Mar 05, 2007 at 11:40:37AM +, Ronny Adsetts wrote:
 Thanks for this. Unfortunately, I'm no longer seeing the server
 crashing as the server on the other end stopped trying to re-deliver
 the email on Friday. I'll see what I can do to get the problem
 reproduced and so get more debug info.
 
 Any news on this? How about contacting the remote side postmaster
 and asking him to send a message?

Hi.

Another follow up on this one. I'm struggling to get a backtrace for this. Can 
one of you provide a little help? I need to either find a way to get exim to 
core dump or to get it to not fork so gdb knows what to do.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 19/03/2007 11:15:
 On Mon, Mar 05, 2007 at 11:40:37AM +, Ronny Adsetts wrote:
 Thanks for this. Unfortunately, I'm no longer seeing the server
 crashing as the server on the other end stopped trying to re-deliver
 the email on Friday. I'll see what I can do to get the problem
 reproduced and so get more debug info.
 
 Any news on this? How about contacting the remote side postmaster
 and asking him to send a message?

OK, I have a crashing delivery attempt every hour and built exim4-daemon-heavy 
with the instructions given in an earlier email. I've also installed 
libgnutls11-dbg. So I guess we have a couple of days until the sending server 
quits retrying the delivery.

If you can you give me brief instructions on using gdb to get a backtrace, that 
would be helpful.

Is there anything else I can do, please let me know.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 19/03/2007 11:15:
 On Mon, Mar 05, 2007 at 11:40:37AM +, Ronny Adsetts wrote:
 Thanks for this. Unfortunately, I'm no longer seeing the server
 crashing as the server on the other end stopped trying to re-deliver
 the email on Friday. I'll see what I can do to get the problem
 reproduced and so get more debug info.
 
 Any news on this? How about contacting the remote side postmaster
 and asking him to send a message?

Thanks for the nudge on this, I'll see what contact details I can dig up and 
see if they'll help out.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 




signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Andreas Metzler said at 03/03/2007 09:41:
 
 I have put unstripped packages on http://www.bebt.de/debian/misc/
 (exim4-daemon-light_4.50-8sarge2+b0_i386.deb and
 exim4-daemon-light_4.50-8sarge2+b0_i386.deb). If you'd rather not
 install binaries from untrusted sources, that is no problem:
 
 1. as root: apt-get build-dep exim4
 2. as regular user
 apt-get install build-essential fakeroot
 apt-get source exim4
 cd exim4-4.50
 export DEB_BUILD_OPTIONS=nostrip
 dpkg-buildpackage -uc -us -rfakeroot
 
 If you are going t provide a backtrace using gdb libgnutls11-dbg will
 be helpful.

Thanks for this. Unfortunately, I'm no longer seeing the server crashing as the 
server on the other end stopped trying to re-deliver the email on Friday. I'll 
see what I can do to get the problem reproduced and so get more debug info.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 01/03/2007 09:13:

On Wed, Feb 28, 2007 at 07:43:16PM +, Ronny Adsetts wrote:


My first thought was hardware failure too, but it's not looking that way at 
the moment. The segfaults are too regular in their timing. I'll see if the 
same happens at 20:08.


What does your exim log say in the respective time frame?


Nothing for the email in the tcpdump gets logged to any of the exim logs AFAICS.

I'm not seeing any problems on this server at all other than this segfault that 
started yesterday at ~3am and continues every hour when the same email is 
retried.

Thanks.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 01/03/2007 09:54:

On Thu, Mar 01, 2007 at 09:50:40AM +, Ronny Adsetts wrote:
I'm not seeing any problems on this server at all other than this segfault 
that started yesterday at ~3am and continues every hour when the same email 
is retried.


So the segfault is associated with a single message?

Please send the output of exim -d -M message-id


exim segfaults before the message is received. The tcpdump captures are of two 
SMTP transactions that result in the segfault.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 01/03/2007 10:08:

On Thu, Mar 01, 2007 at 09:50:40AM +, Ronny Adsetts wrote:

Marc Haber said at 01/03/2007 09:13:

On Wed, Feb 28, 2007 at 07:43:16PM +, Ronny Adsetts wrote:
My first thought was hardware failure too, but it's not looking that way 
at the moment. The segfaults are too regular in their timing. I'll see if 
the same happens at 20:08.


What does your exim log say in the respective time frame?


Nothing for the email in the tcpdump gets logged to any of the exim logs 
AFAICS.


I'm not seeing any problems on this server at all other than this segfault 
that started yesterday at ~3am and continues every hour when the same email 
is retried.


So it is an incoming message? Can you strace -f your exim daemon in
the time frame where you expect the retry to happen?


Strace for the crashing process attached. Command was:

$ sudo strace -ff -o exim_strace /usr/sbin/exim4 -bd -q30m -oX 587:465:25 -oP 
/var/run/exim4/exim.pid

Segfault log:

Mar  1 11:09:16 nakor kernel: exim4[17576]: segfault at  rip 
002a96bbb220 rsp 007fbfffd758 error 4


Does this also happen when you use a backport of a more recent exim
version?


I'll see if I can give it a go in a little while... it's the office mail server 
so have to a little careful. :-)


I'll send a heads-up to the GnuTLS guys.


Not sure from the strace that that's where the problem is... but then I'm not 
much of an strace guru.

Let me know if there's anything else I can do. I'll let you know in a while, if 
I can, whether the current backports.org exim (4.63-17~bpo.1) crashes.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com
getsockname(9, {sa_family=AF_INET, sin_port=htons(48945), 
sin_addr=inet_addr(172.16.1.20)}, [38654705680]) = 0
getpeername(9, 0x7fbfffd8e0, [68719476864])= -1 ENOTCONN (Transport 
endpoint is not connected)
close(3) = 0
close(4)= 0
close(5)= 0
close(6)= 0
close(7)= 0
close(8)= 0
rt_sigaction(SIGCHLD, {SIG_IGN}, NULL, 8) = 0
setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr(172.16.1.20)}, 28) = 0
sendto(3, c*\1\0\0\1\0\0\0\0\0\0\00219\00279\003179\00264\7in-ad..., 43, 0, 
NULL, 0) = 43
gettimeofday({1172747355, 836759}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
recvfrom(3, c*\201\200\0\1\0\1\0\3\0\2\00219\00279\003179\00264\7i..., 2048, 
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(172.16.1.20)}, 
[16]) = 182
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/.nscd_socket}, 110) = 0
writev(3, [{\2\0\0\0\5\0\0\0\33\0\0\0, 12}, {mail.griffinautomation.com\0, 
27}], 2) = 39
read(3, \2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377..., 32) = 32
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/.nscd_socket}, 110) = 0
writev(3, [{\2\0\0\0\4\0\0\0\33\0\0\0, 12}, {mail.griffinautomation.com\0, 
27}], 2) = 39
read(3, \2\0\0\0\1\0\0\0\33\0\0\0\0\0\0\0\2\0\0\0\4\0\0\0\1\0\0..., 32) = 32
readv(3, [{mail.griffinautomation.com\0, 27}, {, 0}, {@\263O\23, 4}], 3) 
= 31
read(3, NULL, 0)= 0
close(3)= 0
getpid()= 17576
time(NULL)  = 1172747356
select(12, [11], NULL, NULL, {0, 0})= 0 (Timeout)
rt_sigaction(SIGTERM, {0x456200, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x456170, [], 0x400}, NULL, 8) = 0
write(10, 220 nakor.amazing-internet.net E..., 80) = 80
alarm(300)  = 0
read(11, EHLO mail.griffinautomation.com\r..., 8192) = 33
alarm(0)= 300
rt_sigaction(SIGALRM, {0x425d50, [], 0x400}, NULL, 8) = 0
getpid()= 17576
rt_sigaction(SIGALRM, {0x456170, [], 0x400}, NULL, 8) = 0
write(10, 250-nakor.amazing-internet.net H..., 139) = 139
alarm(300)  = 0
read(11, STARTTLS\r\n, 8192)  = 10
alarm(0)= 300
rt_sigaction(SIGALRM, {0x425d50, [], 0x400}, NULL, 8) = 0
brk(0)  = 0x5f4000
brk(0x615000)   = 0x615000
brk(0)  = 0x615000
brk(0x636000)   = 0x636000
open(/var/spool/exim4/gnutls-params, O_RDONLY) = 3
read(3, @\0\0\0, 4)   = 4
read(3, \334\311E\3\332\202)M\376+\20s\226\313|W\271\30\347\306..., 64) = 64
read(3, \3\0\0\0, 4)  = 4
read(3, \1\0\1, 3)= 3
read(3, @\0\0\0, 4

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Marc Haber said at 01/03/2007 11:30:

On Thu, Mar 01, 2007 at 11:20:46AM +, Ronny Adsetts wrote:

Strace for the crashing process attached.


Thanks. This unfortunately is not very conclusive.

Again, unfortunately, exim4 in sarge does not yet have a -dbg package.

Can you rebuild the exim packages locally, run an unstripped exim and
see whether you can obtain a backtrace?

Or would you prefer me giving you an unstripped exim package?


If you could provide an unstripped package, this would help me no end. I have 
to get out to the datacentre soon so don't have much time today.


The backports.org packages have functional -dbg packages, so obtaining
a backtrace from backported exim is much easier. I can, however,
understand that you are reluctant to install such beasts on a
production system.


I'll probably try the backports packages outside of office hours later today so 
that I can confirm if the crash is still there in later packages. Assuming the 
server causing the problems continues to connect anyway.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Package: exim4
Version: 4.50-8sarge2
Severity: normal


I've recently, as of early this morning, started to see segfaults from
exim4. I'm seeing this in kern.log:

Feb 28 03:07:02 nakor kernel: exim4[4242]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 03:07:18 nakor kernel: exim4[4244]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 03:07:34 nakor kernel: exim4[4246]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 03:07:51 nakor kernel: exim4[4248]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 03:08:07 nakor kernel: exim4[4249]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4

After this first batch of reports, exim consistently segfaults at 8
minutes past the hour, every hour:

Feb 28 04:08:09 nakor kernel: exim4[11647]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 05:08:11 nakor kernel: exim4[19087]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 06:08:15 nakor kernel: exim4[26456]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 07:08:16 nakor kernel: exim4[1543]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 08:08:17 nakor kernel: exim4[9165]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 09:08:18 nakor kernel: exim4[16584]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 10:08:20 nakor kernel: exim4[24134]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 11:08:23 nakor kernel: exim4[31687]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4
Feb 28 12:08:28 nakor kernel: exim4[7162]: segfault at 
rip 002a96bbb220 rsp 007fbfffd358 error 4
Feb 28 13:08:30 nakor kernel: exim4[14612]: segfault at 
rip 002a96bbb220 rsp 007fbfffd358 error 4
Feb 28 14:08:31 nakor kernel: exim4[22000]: segfault at 
rip 002a96bbb220 rsp 007fbfffd358 error 4
Feb 28 15:08:34 nakor kernel: exim4[29515]: segfault at 
rip 002a96bbb220 rsp 007fbfffd358 error 4
Feb 28 16:08:36 nakor kernel: exim4[4891]: segfault at 
rip 002a96bbb220 rsp 007fbfffd358 error 4
Feb 28 17:08:37 nakor kernel: exim4[12374]: segfault at 
rip 002a96bbb220 rsp 007fbfffd358 error 4

Please let me know if there's any other information you'd like. In the
meantime I'll continue to dig around and see what I can find.

Thanks.

Ronny

-- Package-specific info:
Exim version 4.50 #1 built 01-Jul-2006 17:21:23
Copyright (c) University of Cambridge 2004
Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
Support for: iconv() IPv6 PAM Perl GnuTLS Content_Scanning Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch 
ldap ldapdn ldapm mysql nis nis0 passwd pgsql
Authenticators: cram_md5 cyrus_sasl plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to replace
# the DEBCONFsomethingDEBCONF strings in the configuration template files.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='amazing-internet.net : amazing-internet.com : 
amazinginternet.net : amazinginternet.com : grahamhancock.com : ccldn.org.uk'
dc_local_interfaces=''
dc_readhost='amazing-internet.net'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='172.16.1.0/24 : 172.16.8.0/24'
dc_smarthost='mail.amazing-internet.net'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
mailname:amazing-internet.net

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-12-em64t-p4-smp
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages exim4 depends on:
ii  exim4-base  4.50-8sarge2 support files for all exim MTA (v4
ii  exim4-daemon-heavy  4.50-8sarge2 exim MTA (v4) daemon 

Bug#412886: exim4: Segfaults occurring

[Ronny Adsetts]

Andreas Metzler said at 28/02/2007 19:37:

On 2007-02-28 Ronny Adsetts [EMAIL PROTECTED] wrote:

Package: exim4
Version: 4.50-8sarge2
Severity: normal



I've recently, as of early this morning, started to see segfaults from
exim4. I'm seeing this in kern.log:



Feb 28 03:07:02 nakor kernel: exim4[4242]: segfault at 
rip 002a96bbb220 rsp 007fbfffed58 error 4

[...]

Are you running some special kernel? The regular vanilla Debian
kernels do not report SEGFAULTS of user level programs by syslog
afaik.


$ uname -a
Linux nakor 2.6.8-12-em64t-p4-smp #1 SMP Thu Dec 7 19:12:51 UTC 2006 x86_64 
GNU/Linux

This is the standard Sarge kernel. Well as standard as amd64 got for Sarge.


I might be misreading the message, with exim triggereing a segfault in
the kernel. Anyway if you did not make any recent changes to the
system software and I had to make guess I would point at either a
coruupted harddisk or hardware breakage.


I have a tcpdump of traffic that causes the segfault (attached) to this log 
entry:

Feb 28 19:08:41 nakor kernel: exim4[28068]: segfault at  rip 
002a96bbb220 rsp 007fbfffd358 error 4

My first thought was hardware failure too, but it's not looking that way at the 
moment. The segfaults are too regular in their timing. I'll see if the same 
happens at 20:08.

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com


20070228_190841_crasher.pcap
Description: Binary data


signature.asc
Description: OpenPGP digital signature

Bug#412886: Another tcpdump capture

[Ronny Adsetts]

Here we go, one more (capture attached):

Feb 28 20:08:42 nakor kernel: exim4[3208]: segfault at  rip 
002a96bbb220 rsp 007fbfffd358 error 4

It's the same host, mail.griffinautomation.com, re-trying a delivery.

Is there any other information I can provide?

Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com


20070228_200842_crasher.pcap
Description: Binary data


signature.asc
Description: OpenPGP digital signature

Bug#348046: TLS error occurs on Sarge too

[Ronny Adsetts]

Hi.

This error is occurring with 4.50-8sarge2 on Sarge too. Judging by my munin 
graphs on both sending and receiving side, there's no entropy on the sending 
side. I noticed this error yesterday when there was testing on a client's site 
that resulted in a couple of hundred emails being sent to us in rapid 
succession. The first few were sent on a TLS connection, the remainder had this 
logged on the sending side:

[EMAIL PROTECTED]:~$ grep 1GZ8x3-Ix-Iv /var/log/exim4/mainlog.1
2006-10-15 17:35:01 1GZ8x3-Ix-Iv = [EMAIL PROTECTED] 
H=mainoffice.theclub.chelseaartsclub.com (mainoffice) [172.17.0.189] P=esmtp 
S=612 [EMAIL PROTECTED]
2006-10-15 17:42:36 1GZ8x3-Ix-Iv TLS error on connection to 
mail.amazing-internet.net [172.16.1.20] (gnutls_handshake): A record packet 
with illegal version was received.
2006-10-15 17:42:36 1GZ8x3-Ix-Iv TLS session failure: delivering 
unencrypted to mail.amazing-internet.net [172.16.1.20] (not in 
hosts_require_tls)
2006-10-15 17:42:39 1GZ8x3-Ix-Iv = [EMAIL PROTECTED] R=dnslookup 
T=remote_smtp H=mail.amazing-internet.net [172.16.1.20]
2006-10-15 17:42:39 1GZ8x3-Ix-Iv Completed

This on the receiving side:

2006-10-15 17:42:39 1GZ94O-0003t2-T3 = [EMAIL PROTECTED] 
H=monolith.theclub.chelseaartsclub.com [172.17.0.16] P=esmtp S=822 [EMAIL 
PROTECTED]
2006-10-15 17:42:39 1GZ94O-0003t2-T3 = /dev/null [EMAIL PROTECTED] 
R=ldap_aliases T=**bypassed**
2006-10-15 17:42:39 1GZ94O-0003t2-T3 Completed

Plus lots of these logged on the receiving side:

2006-10-15 17:39:59 TLS error on connection from 
monolith.theclub.chelseaartsclub.com [172.17.0.16] (gnutls_handshake): timed out

So it looks like entropy again is the problem.

A quick google brings up a thread [1] that suggest use of /dev/urandom would 
not be a big deal is some cases. Not sure whether that it feasible from within 
exim though and I suspect not.

[1] http://www.mail-archive.com/help-gnutls@gnu.org/msg00323.html

Is the problem with how greedy gnutls is for random data or in how exim uses 
gnutls?

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#374628: libapache2-mod-php4: Errors sent to error_log do not include timestamps

[Ronny Adsetts]

Package: libapache2-mod-php4
Version: 4:4.3.10-16
Severity: important

Upstream bug appears to be:
http://bugs.php.net/bug.php?id=32587

Bug is marked as done, but no indicaton of where. Will have a go at
tracking it down shortly.

This bug causes the error_log functionality to be less than useful since
you can't tell when anything happened. I'm not sure what the likliehood
of getting a fix in to Sarge is; I'd appreciate someone posting that to
the BTS so I know whether I have to patch and build it myself as it
makes the package fairly unusable for me.

Thanks.

Ronny

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-11-em64t-p4-smp
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages libapache2-mod-php4 depends on:
ii  apache2-mpm-prefork2.0.54-5  traditional model for Apache2
ii  libbz2-1.0 1.0.2-7   high-quality block-sorting file co
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libcomerr2 1.37-2sarge1  common error description library
ii  libdb4.2   4.2.52-18 Berkeley v4.2 Database Libraries [
ii  libexpat1  1.95.8-3  XML parsing C library - runtime li
ii  libkrb53   1.3.6-2sarge2 MIT Kerberos runtime libraries
ii  libmagic1  4.12-1File type determination library us
ii  libpcre3   4.5-1.2sarge1 Perl 5 Compatible Regular Expressi
ii  libssl0.9.70.9.7e-3sarge1SSL shared libraries
ii  libzzip-0-12   0.12.83-4 library providing read access on Z
ii  mime-support   3.28-1MIME files 'mime.types'  'mailcap
ii  php4-common4:4.3.10-16   Common files for packages built fr
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#374628: More info and patches

[Ronny Adsetts]

tag 374628 patch
thanks

So I think I tracked down the changelog and a patch:

PHP changelog entries:
http://www.mail-archive.com/php-cvs-daily@lists.php.net/msg02331.html

PHP diffs:
http://cvs.php.net/viewvc.cgi/php-src/sapi/apache2filter/sapi_apache2.c?view=diffr1=texttr1=1.91.2.26r2=texttr2=1.91.2.27diff_format=u
http://cvs.php.net/viewvc.cgi/php-src/sapi/apache2handler/sapi_apache2.c?view=diffr1=texttr1=1.1.2.39r2=texttr2=1.1.2.40diff_format=u




signature.asc
Description: OpenPGP digital signature

Bug#344038: tinyca: No way to easily see cert expiry

[Ronny Adsetts]

close 344038
thanks

Christoph Ulrich Scholler said at 01/03/2006 23:53:
 
 I have just recently stumbled across the following: In the CA tab, click
 on the History button and you will get a list of all certificates and
 ever signed and their current state.  This view has a column labelled
 Expiration Date, which can be used for sorting.
 
 I will assume that this is satisfactory and unless you object I will close
 this bug in two weeks.

This is fine by me as it does achieve what I wanted to.

In an ideal world of course, I think it would be better if you could 
revoke/renew certs from the History window.

Thanks for maintaining the package!

Ronny
-- 
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#344038: tinyca: No way to easily see cert expiry

[Ronny Adsetts]

Hi uLI,

Christoph Ulrich Scholler said at 02/03/2006 11:15:
 
 On 02.03. 11:03, Ronny Adsetts wrote:
 I have just recently stumbled across the following: In the CA
 tab, click on the History button and you will get a list of all
  certificates and ever signed and their current state.  This view
 has a column labelled Expiration Date, which can be used for
 sorting.
 [...]
 
 In an ideal world of course, I think it would be better if you
 could revoke/renew certs from the History window.
 
 The history window is not modal.  You can open it and then switch to
 the requests or certificates tab in the main window and sign, renew,
 or revoke certificates.  I'm not sure the history window gets
 updated, though.  I haven't (yet) tested this.

Of course, thanks for pointing that out. :-)

I'll check it out next time I have to issue/renew a cert.

Thanks again.

Ronny
-- 
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com



signature.asc
Description: OpenPGP digital signature

Bug#169098: bind9-host: Confirming problems with sarge

[Ronny Adsetts]

Package: bind9-host
Version: 1:9.2.4-1
Followup-For: Bug #169098


I'm having problems getting this to work on Sarge. As this bug states,
ping does the lookup correctly. From my resolv.conf:

search amazing-internet.net theclub.chelseaartsclub.com

Both host binaries from the host and bind9-host packages fail to find
hosts that live in the second domain only:

$ host -v joelaptop
Trying joelaptop.amazing-internet.net
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;joelaptop.amazing-internet.net.IN  A

;; AUTHORITY SECTION:
amazing-internet.net.   86400   IN  SOA amazing-internet.net.
hostmaster.amazing-internet.net. 2821272952 28800 7200 604800 86400

Received 95 bytes from 172.16.1.16#53 in 1 ms


$ host -v joelaptop.theclub.chelseaartsclub.com
Trying joelaptop.theclub.chelseaartsclub.com
;; -HEADER- opcode: QUERY, status: NOERROR, id: 49811
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;joelaptop.theclub.chelseaartsclub.com. IN A

;; ANSWER SECTION:
joelaptop.theclub.chelseaartsclub.com. 300 IN A 172.17.24.186

;; AUTHORITY SECTION:
theclub.chelseaartsclub.com. 86400 IN   NS
dns.theclub.chelseaartsclub.com.

;; ADDITIONAL SECTION:
dns.theclub.chelseaartsclub.com. 86400 IN A 172.17.0.16

Received 105 bytes from 172.16.1.16#53 in 42 ms


If only theclub.chelseaartsclub.com is in the search list, everything
works.

Is there a known solution or workaround to this?

Thanks,
Ronny Adsetts

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-11-em64t-p4-smp
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages bind9-host depends on:
ii  libc6 2.3.2.ds1-22   GNU C Library: Shared libraries an
ii  libdns16  1:9.2.4-1  DNS Shared Library used by BIND
ii  libisc7   1:9.2.4-1  ISC Shared Library used by BIND
ii  libssl0.9.7   0.9.7e-3sarge1 SSL shared libraries

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#349663: amanda-client: Marking files for backup exclusion doesn't work using the XFS fs

[Ronny Adsetts]

Package: amanda-client
Version: 1:2.4.4p3-3
Severity: wishlist


Using chattr +d marks files as not being a candidate for backup. In
order to make this work with xfsdump, you need to use the '-e' option to
xfsdump.

There is a patch here for this:
http://www.mail-archive.com/amanda-users@amanda.org/msg10412.html

The patch is fairly old and I'm not certain it will apply. AFAICS this
functionality is not in the latest version of amanda but sourceforge's
CVS viewer is playing up so can't verify fully.

Thanks for maintaining this package.

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-11-em64t-p4-smp
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages amanda-client depends on:
ii  amanda-common   1:2.4.4p3-3  Advanced Maryland Automatic Networ
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libncurses5 5.4-4Shared libraries for terminal hand
ii  libreadline44.3-11   GNU readline and history libraries

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#344038: tinyca: No way to easily see cert expiry

[Ronny Adsetts]

Package: tinyca
Version: 0.7.0-2
Severity: wishlist

In would be really handy to have an 'Expiry' column in the certificates
view. This would make it much less painful to determine which certs are
due to expire.

Thanks.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages tinyca depends on:
ii  libgnome2-perl1.023-1Perl interface to the GNOME librar
ii  libgtk2-perl  1:1.101-1  Perl interface to the 2.x series o
ii  liblocale-gettext-perl1.05-1 Using libc functions for internati
ii  openssl   0.9.8a-3   Secure Socket Layer (SSL) binary a

Versions of packages tinyca recommends:
ii  zip   2.31-3 Archiver for .zip files

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#278161: Unable to reproduce XFS panic

[Ronny Adsetts]

Hi,
I ran the stresstest.sh script on a newly installed Sarge box last week and it 
completed fine. Setup is XFS on LVM on hardware RAID 5
Config:
Debian information:
release: Sarge
kernel:  kernel-image-2.6.8-2-686-smp2.6.8-13
libc6: 2.3.2.ds1-21
Hardware information:
Server model: Supermicro 5033CT
CPU model: Intel(R) Pentium(R) 4 CPU 3.20GHz
Number of CPUs: 1
Memory installed: 1GB
Disk controller: RAID bus controller: 3ware Inc 3ware ATA-RAID 9000 series
Array configuration: Raid 5 (4 disk)
Ronny
--
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com


signature.asc
Description: OpenPGP digital signature

Bug#281372: Crashed again despite firmware upgrade (#281372)

[Ronny Adsetts]

Damn, I really must learn how to use the BTS properly... resending to the BTS.
As mentioned in the earlier email, I flashed the RAID card to the latest Dell
firmware. The server bailed last night. From kern.log on a remote logging host:
Jan 25 00:54:47 tardis kernel: aacraid: Host adapter reset request. SCSI hang ?
Jan 25 00:54:47 tardis kernel: scsi: device set offline - command error
recover failed: host 0 channel 0 id 0 lun 0
Jan 25 00:54:47 tardis kernel:  I/O error: dev 08:06, sector 1506680
Jan 25 00:54:47 tardis kernel: SCSI disk error : host 0 channel 0 id 0 lun 0
return code = 600
Jan 25 00:54:47 tardis kernel:  I/O error: dev 08:06, sector 1953513
Jan 25 00:54:47 tardis kernel:  I/O error: dev 08:06, sector 1953520
Jan 25 00:54:47 tardis kernel: I/O error in filesystem (sd(8,6)) meta-data
dev sd(8,6) block 0x1dcee9   (xlog_iodone) error 5 buf count 3584
Jan 25 00:54:47 tardis kernel:  I/O error: dev 08:06, sector 1506680
Jan 25 00:54:47 tardis kernel: xfs_force_shutdown(sd(8,6),0x2) called from
line 959 of file xfs_log.c.  Return address = 0xf89274aa
$ lspci -vvv
00:04.0 RAID bus controller: Digital Equipment Corporation DECchip 21554 (rev 
01)
Subsystem: Adaptec Dell PowerEdge RAID Controller 2
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 128, cache line size 08
Interrupt: pin A routed to IRQ 61
Region 0: Memory at f400 (32-bit, non-prefetchable) [size=8K]
Region 1: I/O ports at 1000 [size=256]
Expansion ROM at unassigned [disabled] [size=128K]
Capabilities: available only to root
$ cat /proc/scsi/aacraid/0
Adaptec Raid Controller 1.1-3 Nov 14 2004 11:01:31, scsi hba number 0
kernel: 2.8-4[6089]
monitor: 2.8-4[6089]
bios: 2.8-0[6089]
serial: 895e87fafaf001
$ uname -a
Linux tardis 2.4.27-ainet-p3-smp #1 SMP Sun Nov 14 10:54:19 GMT 2004 i686
GNU/Linux
Built from kernel-source-2.4.27 (2.4.27-5).
I'll build a kernel from the latest debian 2.4.27 (2.4.27-8) and reboot this
evening, though bear in mind that the server has taken up to ~40 days to crash
in the past.
Yell if you need more info.
Ronny
--
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]