Bug#732550: Backtraces

[Martin von Wittich]

I figured out how to keep the coredumps with corekeeper and how to get
the backtraces. I've attached the backtraces of three crashes from
6090b3dc; I hope they help to isolate this issue. If you need more
details from the coredumps, I can retrieve those (please post the
necessary gdb instructions, I'm not too familiar with gdb), but for data
privacy reasons, I'm unfortunately unable to post the complete coredumps
here because they contain private mails of our users.

Martin
(gdb) bt
#0  0x08119e2c in Perl_leave_scope (my_perl=my_perl@entry=0xa1b4008, base=368) 
at scope.c:738
#1  0x0811ab77 in Perl_pop_scope (my_perl=my_perl@entry=0xa1b4008) at 
scope.c:110
#2  0x08122b49 in Perl_die_unwind (my_perl=my_perl@entry=0xa1b4008, 
msv=msv@entry=0xc727430) at pp_ctl.c:1759
#3  0x080c5ef6 in Perl_croak_sv (my_perl=my_perl@entry=0xa1b4008, 
baseex=baseex@entry=0xa1b779c) at util.c:1579
#4  0x080c5f17 in Perl_die_sv (my_perl=my_perl@entry=0xa1b4008, 
baseex=0xa1b779c) at util.c:1512
#5  0x080d2707 in Perl_sighandler (sig=14, sip=0x33, uap=0x0) at mg.c:3138
#6  
#7  0x08142d2c in S_regcppop (my_perl=my_perl@entry=0xa1b4008, 
rex=rex@entry=0xb455ea0) at regexec.c:418
#8  0x08147533 in S_regmatch (prog=0xb4711fc, reginfo=0xbfd97ec8, 
my_perl=0xa1b4008) at regexec.c:4757
#9  S_regtry (my_perl=my_perl@entry=0xa1b4008, 
reginfo=reginfo@entry=0xbfd97ec8, startpos=startpos@entry=0xbfd97dec) at 
regexec.c:2622
#10 0x0814edfe in S_find_byclass (my_perl=my_perl@entry=0xa1b4008, 
prog=prog@entry=0xb455ea0, c=c@entry=0xb4711fc, s=0xc8e218f ' ' , "\nab 60 €U\002",
s@entry=0xc8e2118 "--645945410240351\nContent-Type: text/plain; 
charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\nUnsere Besten:\n\nBinz, 
Loev", ' ' , "\nab 60 €U\002",
strend=strend@entry=0xc916f7a ">\n\n 
\n--645945410240351--\n", reginfo=reginfo@entry=0xbfd97ec8) at regexec.c:1416
#11 0x0815510f in Perl_regexec_flags (my_perl=0xa1b4008, rx=0xb43b9d0,
stringarg=0xc8e2118 "--645945410240351\nContent-Type: text/plain; 
charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\nUnsere Besten:\n\nBinz, 
Loev", ' ' , "\nab 60 €U\002",
strend=0xc916f7a ">\n\n \n--645945410240351--\n",
strbeg=0xc8e2118 "--645945410240351\nContent-Type: text/plain; 
charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\nUnsere Besten:\n\nBinz, 
Loev", ' ' , "\nab 60 €U\002", minend=0,
sv=0xb4371b4, data=0x0, flags=3) at regexec.c:2350
#12 0x080e63e9 in Perl_pp_match (my_perl=0xa1b4008) at pp_hot.c:1386
#13 0x080e2898 in Perl_runops_standard (my_perl=0xa1b4008) at run.c:41
#14 0x0807ede0 in S_run_body (oldscope=, my_perl=) at perl.c:2345
#15 perl_run (my_perl=0xa1b4008) at perl.c:2268
#16 0x0806124f in main (argc=8, argv=0xbfd98194, env=0xbfd981b8) at 
perlmain.c:120
(gdb) bt
#0  0x08119d02 in Perl_leave_scope (my_perl=my_perl@entry=0x9d1d008, base=406) 
at scope.c:777
#1  0x0811ab77 in Perl_pop_scope (my_perl=my_perl@entry=0x9d1d008) at 
scope.c:110
#2  0x08122b49 in Perl_die_unwind (my_perl=my_perl@entry=0x9d1d008, 
msv=msv@entry=0xc51728c) at pp_ctl.c:1759
#3  0x080c5ef6 in Perl_croak_sv (my_perl=my_perl@entry=0x9d1d008, 
baseex=baseex@entry=0x9d2079c) at util.c:1579
#4  0x080c5f17 in Perl_die_sv (my_perl=my_perl@entry=0x9d1d008, 
baseex=0x9d2079c) at util.c:1512
#5  0x080d2707 in Perl_sighandler (sig=14, sip=0x33, uap=0x0) at mg.c:3138
#6  
#7  0x08142d32 in S_regcppop (my_perl=my_perl@entry=0x9d1d008, 
rex=rex@entry=0xafc3fa8) at regexec.c:418
#8  0x08147533 in S_regmatch (prog=0xafb323c, reginfo=0xbfd6dd48, 
my_perl=0x9d1d008) at regexec.c:4757
#9  S_regtry (my_perl=my_perl@entry=0x9d1d008, 
reginfo=reginfo@entry=0xbfd6dd48, startpos=startpos@entry=0xbfd6dc6c) at 
regexec.c:2622
#10 0x0814edfe in S_find_byclass (my_perl=my_perl@entry=0x9d1d008, 
prog=prog@entry=0xafc3fa8, c=c@entry=0xafb323c, 
s=0xd3623ca "\n", '=' , "\n", ' ' , 
"Smeet NewsletterU\002", 
s@entry=0xd362358 "--b1_7249a8dfcf91bf10ce3b08d0b3585c35\nContent-Type: 
text/plain; charset = \"UTF-8\"\nContent-Transfer-Encoding: 8bit\n\n", '=' 
, "\n", ' ' ..., 
strend=strend@entry=0xd366422 "-b1_7249a8dfcf91bf10ce3b08d0b3585c35--\n", 
reginfo=reginfo@entry=0xbfd6dd48) at regexec.c:1416
#11 0x0815510f in Perl_regexec_flags (my_perl=0x9d1d008, rx=0xafa52d4, 
stringarg=0xd362358 "--b1_7249a8dfcf91bf10ce3b08d0b3585c35\nContent-Type: 
text/plain; charset = \"UTF-8\"\nContent-Transfer-Encoding: 8bit\n\n", '=' 
, "\n", ' ' ..., 
strend=0xd366422 "-b1_7249a8dfcf91bf10ce3b08d0b3585c35--\n", 
strbeg=0xd362358 "--b1_7249a8dfcf91bf10ce3b08d0b3585c35\nContent-Type: 
text/plain; charset = \"UTF-8\"\nContent-Transfer-Encoding: 8bit\n\n", '=' 
, "\n", ' ' ..., 
minend=0, sv=0xafa4eec, data=0x0, flags=3) at regexec.c:2350
#12 0x080e63e9 in Perl_pp_match (my_perl=0x9d1d008) at pp_hot.c:1386
#13 0x080e2898 in Perl_runops_standard (my_perl=0x9d1d008) at run.c:41
#14 0x0807ede0 in S_run_body (oldscope=, my_perl=) at perl.c:2345
#15 perl_run (my_perl=0x9d1d008) at perl.c:2268
#16 0x0806124f in main (argc=8

Bug#737129: webalizer refuses to read symlinked log files

[Martin von Wittich]

Hi Julien,

>> Could the
>> original behaviour be restored so that our configuration works again?
> Even if I changed it now, it would go to jessie at best, so you'd need a
> backport anyway. So you can probably just build a local patched version.
> 
> One way to fix your use case could be to update your shell script to use
> hardlink instead of symlink.

Yes, I've resolved the issue in our configuration by replacing the
symlink with a copy of the original file. A hardlink would probably have
been a more elegant solution, but I didn't think of that at the time ^^

I think it would be still worthwhile to forward this issue upstream so
it could possibly resolved in a future version, but I don't need a
short-term solution anymore :)

-- 
Mit freundlichen Grüßen,

Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:martin.von.witt...@iserv.eu
Internet:  iserv.eu

USt.-IdNr.:   DE265149425
Registergericht:  Amtsgericht Braunschweig
Registernummer:   HRB 201822
Geschäftsführer:  Jörg Ludwig


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

Bug#736835: php-htmlpurifier: "Undefined index" notice due to bug in library/HTMLPurifier/AttrDef/HTML/Color.php

[Martin von Wittich]

Package: php-htmlpurifier
Version: 4.4.0+dfsg1-1
Severity: normal

Dear Maintainer,

the following code raises a notice:

purify("test");

?>

Notice: Undefined index: Green in
/usr/share/php-htmlpurifier/library/HTMLPurifier/AttrDef/HTML/Color.php
on line 17


This is caued by a bug in
/usr/share/php-htmlpurifier/library/HTMLPurifier/AttrDef/HTML/Color.php
on line 17 - the code use strtolower($string) to check for the existence
of an array element, but then uses $string to access it.

if (isset($colors[strtolower($string)])) return $colors[$string];

The issue is apparently already resolved upstream, because the most
recent version uses strtolower in both cases. I've attached a small
patch that fixes the issue in the current Debian version.

-- System Information:
Debian Release: 7.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php-htmlpurifier depends on:
ii  php5  5.4.4-14+deb7u7

Versions of packages php-htmlpurifier recommends:
ii  php5-cli  5.4.4-14+deb7u7

php-htmlpurifier suggests no packages.

-- no debconf information
--- Color.php.orig	2012-01-19 01:24:10.0 +0100
+++ Color.php	2014-01-27 12:48:27.0 +0100
@@ -14,7 +14,7 @@
 $string = trim($string);
 
 if (empty($string)) return false;
-if (isset($colors[strtolower($string)])) return $colors[$string];
+if (isset($colors[strtolower($string)])) return $colors[strtolower($string)];
 if ($string[0] === '#') $hex = substr($string, 1);
 else $hex = $string;
 

Bug#732460: imvirt: "Unexpected output from lspci" parsing bug

[Martin von Wittich]

Package: imvirt
Version: 0.9.6-1
Severity: normal

Dear Maintainer,

I'm getting the following error when running imvirt on one of our
servers:

host ~ # imvirt
Unexpected output from lspci: 00:1a.0 "USB controller" "Intel Corporation" "6 
Series/C200 Series Chipset Family USB Enhanced Host Controller #2" -r05 -p20 
"Intel Corporation" "Apple MacBookPro8,2 [Core i7, 15\", 2011]"
Unexpected output from lspci: 00:1d.0 "USB controller" "Intel Corporation" "6 
Series/C200 Series Chipset Family USB Enhanced Host Controller #1" -r05 -p20 
"Intel Corporation" "Apple MacBookPro8,2 [Core i7, 15\", 2011]"
Unexpected output from lspci: 00:1f.3 "SMBus" "Intel Corporation" "6 
Series/C200 Series Chipset Family SMBus Controller" -r05 "Intel Corporation" 
"Apple MacBookPro8,2 [Core i7, 15\", 2011]"
Physical

Apparently the regex in /usr/share/perl5/ImVirt/Utils/pcidevs.pm doesn't cope
with the quoted " in "Apple MacBookPro8,2 [Core i7, 15\", 2011]" in the lspci
output:

host ~ # lspci -m
00:00.0 "Host bridge" "Intel Corporation" "Xeon E3-1200 Processor Family DRAM 
Controller" -r09 "Intel Corporation" "Device 2010"
00:19.0 "Ethernet controller" "Intel Corporation" "82579LM Gigabit Network 
Connection" -r05 "Intel Corporation" "Device 3578"
00:1a.0 "USB controller" "Intel Corporation" "6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2" -r05 -p20 "Intel Corporation" "Apple 
MacBookPro8,2 [Core i7, 15\", 2011]"
00:1c.0 "PCI bridge" "Intel Corporation" "6 Series/C200 Series Chipset Family 
PCI Express Root Port 1" -rb5 "" ""
00:1c.4 "PCI bridge" "Intel Corporation" "6 Series/C200 Series Chipset Family 
PCI Express Root Port 5" -rb5 "" ""
00:1c.5 "PCI bridge" "Intel Corporation" "6 Series/C200 Series Chipset Family 
PCI Express Root Port 6" -rb5 "" ""
00:1d.0 "USB controller" "Intel Corporation" "6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #1" -r05 -p20 "Intel Corporation" "Apple 
MacBookPro8,2 [Core i7, 15\", 2011]"
00:1e.0 "PCI bridge" "Intel Corporation" "82801 PCI Bridge" -ra5 -p01 "" ""
00:1f.0 "ISA bridge" "Intel Corporation" "C204 Chipset Family LPC Controller" 
-r05 "Intel Corporation" "Device 7270"
00:1f.2 "SATA controller" "Intel Corporation" "6 Series/C200 Series Chipset 
Family SATA AHCI Controller" -r05 -p01 "Intel Corporation" "Device 7270"
00:1f.3 "SMBus" "Intel Corporation" "6 Series/C200 Series Chipset Family SMBus 
Controller" -r05 "Intel Corporation" "Apple MacBookPro8,2 [Core i7, 15\", 2011]"
02:00.0 "Ethernet controller" "Intel Corporation" "82574L Gigabit Network 
Connection" "Intel Corporation" "Device 3578"
03:00.0 "VGA compatible controller" "Matrox Electronics Systems Ltd." "MGA 
G200e [Pilot] ServerEngines (SEP1)" -r07 "Intel Corporation" "Device 0102"

(The server is not a MacBook btw, but that's probably a different bug report
for the pciutils package :)

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

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imvirt depends on:
ii  dpkg1.16.12
ii  libimvirt-perl  0.9.6-1
ii  perl5.14.2-21+deb7u1

imvirt recommends no packages.

imvirt 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#732550: spamassassin: spamd child segfaulting since updating to wheezy

[Martin von Wittich]

Package: spamassassin
Version: 3.3.2-5
Severity: normal

Dear Maintainer,

we're currently in the process of updating our customer servers to
Debian wheezy.  On a specific server, we're seeing a lot of "spamd
child" segfaults that started occuring some days after the upgrade to
Debian wheezy:

host ~ # zgrep segfault /var/log/syslog*
/var/log/syslog:Dec 18 11:03:23 iserv kernel: [21705301.867857] spamd 
child[6661]: segfault at 127 ip 0811a0ca sp bfd468a0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:18 iserv kernel: [21646077.256066] spamd 
child[17653]: segfault at 1dc ip 080f1543 sp bf9963b0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:20 iserv kernel: [21646079.152118] spamd 
child[17657]: segfault at 41485851 ip 0810c14d sp bf996fb0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:30 iserv kernel: [21646088.667283] spamd 
child[4999]: segfault at 1f3 ip 0811a0ca sp bf9963c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:33 iserv kernel: [21646091.712060] spamd 
child[17728]: segfault at 1dc ip 0811a0ca sp bf9963c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:40 iserv kernel: [21646098.816061] spamd 
child[17724]: segfault at d ip 0811a0ca sp bf9963c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:30 iserv kernel: [21444669.196066] spamd 
child[23107]: segfault at 1d9 ip 0811a0cd sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:41 iserv kernel: [21444680.120097] spamd 
child[23203]: segfault at 1f5 ip 08062783 sp bfea90a0 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:42 iserv kernel: [21444680.832068] spamd 
child[23226]: segfault at 1e7 ip 0811a0ca sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:42 iserv kernel: [21444680.885186] spamd 
child[23224]: segfault at d ip 08119bfa sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:42 iserv kernel: [21444680.992067] spamd 
child[23227]: segfault at 1e7 ip 0811a0ca sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:43 iserv kernel: [21444682.021580] spamd 
child[10011]: segfault at d ip 0811a0ca sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:52 iserv kernel: [21444690.963868] spamd 
child[23225]: segfault at 1c4 ip 0811a0cd sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:53 iserv kernel: [21444691.672664] spamd 
child[23201]: segfault at d ip 0811a0ca sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.3.gz:Dec 15 10:39:57 iserv kernel: [21444695.560107] spamd 
child[23228]: segfault at 1f5 ip 0811a0ca sp bfea9090 error 4 in 
perl[8048000+169000]
/var/log/syslog.4.gz:Dec 14 10:17:55 iserv kernel: [21356973.612057] spamd 
child[22345]: segfault at 275 ip 08119a92 sp bf8863c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.4.gz:Dec 14 10:18:05 iserv kernel: [21356983.664101] spamd 
child[22344]: segfault at d ip 0811a0ca sp bf8863c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.4.gz:Dec 14 10:18:06 iserv kernel: [21356985.408060] spamd 
child[22361]: segfault at d ip 0811a0ca sp bf886400 error 4 in 
perl[8048000+169000]
/var/log/syslog.4.gz:Dec 14 10:18:16 iserv kernel: [21356995.500051] spamd 
child[22362]: segfault at d ip 0811a0ca sp bf886400 error 4 in 
perl[8048000+169000]
/var/log/syslog.4.gz:Dec 14 10:18:18 iserv kernel: [21356997.071523] spamd 
child[22372]: segfault at 1e9 ip 0811a0ca sp bf8863c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:49:51 iserv kernel: [21175289.870804] spamd 
child[11932]: segfault at 1e2 ip 0811a0cd sp bf91ea80 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:02 iserv kernel: [21175301.056806] spamd 
child[11933]: segfault at 1ce ip 0811a0ca sp bf91ea80 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:02 iserv kernel: [21175301.280057] spamd 
child[12687]: segfault at d ip 0811a0ca sp bf91ea80 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:11 iserv kernel: [21175310.148060] spamd 
child[12668]: segfault at 255 ip 08119c3a sp bf91eac0 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:13 iserv kernel: [21175311.912064] spamd 
child[12688]: segfault at 1 ip 08119cb5 sp bf91eac0 error 6 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:22 iserv kernel: [21175321.528058] spamd 
child[12777]: segfault at 1e2 ip 0811a0cd sp bf91eac0 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:23 iserv kernel: [21175321.548110] spamd 
child[12778]: segfault at 1dc ip 0811a0ca sp bf91ea80 error 4 in 
perl[8048000+169000]
/var/log/syslog.6.gz:Dec 12 07:50:25 iserv kernel: [21175323.876066] spamd 
child[12744]: segfault at 1e0 ip 0811a0cd sp bf91eac0 error 4 in 
perl[8048000+169000]

I've checked the logs of the past 4 months - the upgrade to Debian
wheezy was on 2013-12-04, and the segfaults started on 2013-12-09.

Bug#735554: screen: "Screen owner name too long - sorry" error when attaching to multiuser screen

[Martin von Wittich]

Package: screen
Version: 4.1.0~20120320gitdb59704-7
Severity: normal
Tags: patch

Dear Maintainer,

when attaching to a screen that is owned by a different user with a long
name (> 20 characters), I get the following error:

host ~ # screen -x this-is-a-very-long-username/
Screen owner name too long - sorry.

screen originally had a limit of 20 characters for usernames and
wouldn't work at all if your username was longer, but this was mostly
fixed in a Debian patch. Apparently the patch overlooked this specific
situation so that this issue still occurs.

I've attached a patch that resolved this issue for me.


-- System Information:
Debian Release: 7.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages screen depends on:
ii  dpkg  1.16.12
ii  install-info  4.13a.dfsg.1-10
ii  libc6 2.13-38
ii  libncurses5   5.9-10
ii  libpam0g  1.1.3-7.1
ii  libtinfo5 5.9-10

screen recommends no packages.

Versions of packages screen suggests:
pn  iselect | screenie | byobu  

-- Configuration Files:
/etc/screenrc changed [not included]

-- debconf information excluded
Description: fix "Screen owner name too long - sorry" error
 The patch 49long-usernames.patch increases the maximum user name length that
 screen supports from 20 to 50 characters. Unfortunately, the limit still
 applies when trying to attach to a multiuser screen:
 .
 host ~ # screen -x verylongusername/
 Screen owner name too long - sorry.
 .
 This patch raises the length limit for owner names too.
 .
 screen (4.1.0~20120320gitdb59704-7) unstable; urgency=low
 .
   * Extend 60-644788-screen-4.1.0-4.0.3-interoperability.patch:
 + Add support for detaching (Closes: #684342)
 + Document remaining issues in debian/NEWS
Author: Axel Beckert 
Bug-Debian: http://bugs.debian.org/684342

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Author: Martin von Wittich 
Last-Update: 2014-01-16

--- screen-4.1.0~20120320gitdb59704.orig/screen.c
+++ screen-4.1.0~20120320gitdb59704/screen.c
@@ -1000,7 +1000,7 @@ char **av;
   if (strlen(LoginName) > MAX_USERNAME_LEN)
 Panic(0, "LoginName too long - sorry.");
 #ifdef MULTIUSER
-  if (multi && strlen(multi) > 20)
+  if (multi && strlen(multi) > MAX_USERNAME_LEN)
 Panic(0, "Screen owner name too long - sorry.");
 #endif
   if (strlen(home) > MAXPATHLEN - 25)

Bug#728692: acpi-support breaks Intel I210 Gigabit by enabling power saving

[Martin von Wittich]

Package: acpi-support
Version: 0.140-5
Severity: normal

We recently received new servers with Asus P9D-I mainboards. These mainboards
have two Intel I210 NICs onboard:

root@debian:~# lspci
00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06)
00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host Controller 
(rev 05)
00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host 
Controller #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #1 (rev 
d5)
00:1c.1 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #2 (rev 
d5)
00:1c.2 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #3 (rev 
d5)
00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host 
Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA Controller 1 
[AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 05)
01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)
03:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 02)
04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics 
Family (rev 21)

Both NICs are connected to a switch. Unfortunately, these NICs had weird issues
whenever we installed our Debian-based system (essentially Debian wheezy, but
with a lot of packages preinstalled). Sometimes both NICs were affected,
sometimes only one (usually eth1). They would show up in ifconfig:

root@debian:~# ifconfig -a
eth0  Link encap:Ethernet  HWaddr ac:22:0b:8b:30:a7  
  inet addr:10.255.236.255  Bcast:10.255.255.255  Mask:255.0.0.0
  inet6 addr: fe80::ae22:bff:fe8b:30a7/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
  RX packets:1324 errors:0 dropped:0 overruns:0 frame:0
  TX packets:168 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:107124 (104.6 KiB)  TX bytes:25199 (24.6 KiB)
  Memory:dfe0-dfe8 

eth1  Link encap:Ethernet  HWaddr ac:22:0b:8b:30:a8  
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Memory:dfd0-dfd8 

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

But enabling the affected NIC or accessing it with ethtool would fail:

root@debian:~# ifconfig eth1 up
SIOCSIFFLAGS: No such device

root@debian:~# dhclient eth1
RTNETLINK answers: No such device

root@debian:~# ethtool eth1
Settings for eth1:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available


After we noticed that a clean Wheezy installation was not affected, we looked
for differences between the clean installation and our system, and we tracked
the issue down to acpi-support. The following command from the init script:

root@debian:~# grep -m1 on_ac_power /etc/init.d/acpi-support
on_ac_power || /etc/acpi/power.sh true

behaves unexpectedly because on_ac_power returns 255 on these servers:

root@debian:~# on_ac_power ; echo $?
255

It therefore believes that the server is on battery power, and enables power
saving. This in turn modifies the NICs - I believe the relevant section from
/var/log/pm-powersave.log is this one:

Running hook /usr/lib/pm-utils/power.d/pci_devices true:
Setting Host Bridge :00:00.0 to auto
Setting Ethernet device :01:00.0 to auto
Setting Ethernet device :02:00.0 to auto

This seems to be the cause for our issue. We will resolve the issue by
replacing acpi-support with acpi-support-base in our system dependencies, but I
filed this bug anyway because this issue was very hard to track down and the
information could be useful for others.

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

Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpi-support depends on:
ii  acpi-fakekey   0.140-5
ii  acpi-support-base  0.140-5
ii  acpid  1:2.0.16-1+deb7u1
ii  lsb-base   

Bug#702201: Patch

[Martin von Wittich]

tags 702201 +patch
thanks

I've attached a patch that enables the `delaycompress` flag and also fixes the 
nmbd reload by using `smbcontrol nmbd reload-config` instead of sending SIGHUP.

-- 
Mit freundlichen Grüßen,
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig
--- /etc/logrotate.d/samba.orig
+++ /etc/logrotate.d/samba	2014-06-27 14:49:55.081867734 +0200
@@ -6,6 +6,7 @@
 		/etc/init.d/smbd reload > /dev/null
 	endscript
 	compress
+	delaycompress
 	notifempty
 }
 
@@ -14,8 +15,10 @@
 	missingok
 	rotate 7
 	postrotate
-		[ ! -f /var/run/samba/nmbd.pid ] || kill -HUP `cat /var/run/samba/nmbd.pid`
+		smbcontrol nmbd reload-config
 	endscript
 	compress
+	delaycompress
 	notifempty
 }
+

Bug#732550: (no subject)

[Martin von Wittich]

I believe I have isolated the issue to the Debian packaging of Perl.
I've run the following tests:

2014-02-13   I installed SA 3.4.0 manually with cpanm[1].

2014-02-25   spamd has crashed 10 times since 2014-02-14,
 so the issue is still there.
2014-02-25   I compiled Perl 5.18.2 with Perlbrew[2] and SA 3.4.0
 with cpanm.

2014-03-10   spamd has crashed 0 times since 2014-02-26.
2014-03-10   I compiled Perl 5.14.2 with Perlbrew and SA 3.4.0
 with cpanm to make sure that the issue isn't caused by
 a Perl bug that may have been fixed in 5.18.2.

2014-03-28   spamd has crashed 0 times since 2014-03-11.


As the issue is no longer reproducible with a manually built Perl 5.14.2
(the same version that Debian wheezy has), I conclude that the issue is
most probably caused by the Debian packaging of Perl (maybe a Debian
patch?).

[1] http://search.cpan.org/~miyagawa/App-cpanminus-1.7001/bin/cpanm
[2] http://perlbrew.pl/

Martin


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

Bug#743184: perl: SpamAssassin spamd segfaults since updating servers to Debian wheezy

[Martin von Wittich]

Package: perl
Version: 5.14.2-21+deb7u1
Severity: normal

Dear Maintainer,

since we've updated our customer servers (about 1000) to Debian wheezy,
we're seeing a lot of "spamd child" segfaults on many of these servers.
I've already filed a bug to the spamassassin package[1] back in Dec 2013
when we first noticed the issue, but after investigating the issue, I
think I've now isolated the cause in the Debian packaging of Perl
itself, so I'm filing this bug now against the Perl package.

The symptom of the issue is that dmesg/syslog report a lot of segfaults
of spamd (which is a Perl script):

host ~ # zgrep segfault /var/log/syslog*
/var/log/syslog:Dec 18 11:03:23 iserv kernel: [21705301.867857] spamd 
child[6661]: segfault at 127 ip 0811a0ca sp bfd468a0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:18 iserv kernel: [21646077.256066] spamd 
child[17653]: segfault at 1dc ip 080f1543 sp bf9963b0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:20 iserv kernel: [21646079.152118] spamd 
child[17657]: segfault at 41485851 ip 0810c14d sp bf996fb0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:30 iserv kernel: [21646088.667283] spamd 
child[4999]: segfault at 1f3 ip 0811a0ca sp bf9963c0 error 4 in 
perl[8048000+169000]
/var/log/syslog.1:Dec 17 18:36:33 iserv kernel: [21646091.712060] spamd 
child[17728]: segfault at 1dc ip 0811a0ca sp bf9963c0 error 4 in 
perl[8048000+169000]
[...]

In the last seven days, spamd segfaulted on 64 of our customer servers (out of
a total of 932 servers that I checked). I have attached three backtraces to the
original spamd bug report; please see those for details.

To isolate the issue, I have run the following experiments on one of the
affected servers (SA = SpamAssassin):

2014-02-13   I installed SA 3.4.0 manually with cpanm[2].

2014-02-25   spamd has crashed 10 times since 2014-02-14,
 so a manual SA installation didn't resolve it.
2014-02-25   I compiled Perl 5.18.2 with Perlbrew[3] and again
 installed SA 3.4.0 with cpanm.

2014-03-10   spamd has crashed 0 times since 2014-02-26, so the custom
 Perl 5.18.2 build doesn't seem to be affected.
2014-03-10   I compiled Perl 5.14.2 with Perlbrew and SA 3.4.0
 with cpanm to make sure that the issue isn't caused by
 a Perl bug that may have been fixed in Perl 5.18.2.

2014-03-28   spamd has crashed 0 times since 2014-03-11,
 so the custom Perl 5.14.2 build isn't affected either.

This leads me to my conclusion that the issue must be somehow caused by the
Debian packaging of Perl... maybe a Debian patch or something?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732550
[2] http://search.cpan.org/~miyagawa/App-cpanminus-1.7001/bin/cpanm
[3] http://perlbrew.pl/

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages perl depends on:
ii  libbz2-1.01.0.6-4
ii  libc6 2.13-38+deb7u1
ii  libdb5.1  5.1.29-5
ii  libgdbm3  1.8.3-11
ii  perl-base 5.14.2-21+deb7u1
ii  perl-modules  5.14.2-21+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages perl recommends:
ii  netbase  5.0

Versions of packages perl suggests:
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make3.81-8.2
ii  perl-doc5.14.2-21+deb7u1

-- 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#743184: perl: SpamAssassin spamd segfaults since updating servers to Debian wheezy

[Martin von Wittich]

> The bug seems unfortunately hard to reproduce by others, so I'm going
> to have to ask you to help some more. See below. If you can come up with
> a recipe to trigger a crash, that would help a lot.

I'd like to, but unfortunately I don't know how yet. Is it possible to use gdb
to identify the code that perl has been executing when it crashed? I'm not too
familiar with gdb, but I hope that this may lead to a recipe.

> So, as a further data point, could you please try with upstream 5.14.4,
> compiled with at least -Dusethreads -Duse64bitint -Duselargefiles, and
> maybe also the gcc flags from dpkg-buildflags ? (See debian/config.debian
> in the perl source package.) Note that these compilation options change
> the ABI so you'll have to reinstall all the CPAN modules too.

I've ignored the flags from from config.debian for the time being because there
are a lot and I don't understand which ones I need... most of them seem to
modify the installation paths, and I think that would be counterproductive for
my test builds. I've now compiled Perl 5.14.4 with the following command:


host ~ # ~/perl5/perlbrew/bin/perlbrew install 5.14.4 -Dusethreads 
-Duse64bitint -Duselargefiles
Fetching perl 5.14.4 as 
/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/dists/perl-5.14.4.tar.bz2
Download http://www.cpan.org/src/5.0/perl-5.14.4.tar.bz2 to 
/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/dists/perl-5.14.4.tar.bz2
Installing 
/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/build/perl-5.14.4
 into ~/perl5/perlbrew/perls/perl-5.14.4

This could take a while. You can run the following command on another shell to 
track the status:

  tail -f ~/perl5/perlbrew/build.perl-5.14.4.log

perl-5.14.4 is successfully installed.


perl -V seems to confirm that the compile flags worked (see attachment
perl-v.txt). I will now rebuild SA and leave that running for a while to see if
it crashes again.
host ~ # ~/perl5/perlbrew/perls/perl-5.14.4/bin/perl -V
Summary of my perl5 (revision 5 version 14 subversion 4) configuration:

  Platform:
osname=linux, osvers=3.2.0-0.bpo.4-686-pae, 
archname=i686-linux-thread-multi-64int
uname='linux host 3.2.0-0.bpo.4-686-pae #1 smp debian 3.2.41-2~bpo60+1 i686 
gnulinux '
config_args='-de 
-Dprefix=/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/perls/perl-5.14.4
 -Dusethreads -Duse64bitint -Duselargefiles 
-Aeval:scriptdir=/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/perls/perl-5.14.4/bin'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.7.2', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib 
/usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=libc-2.13.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.13'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib 
-fstack-protector'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV USE_64_BIT_INT USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
USE_REENTRANT_API
  Built under linux
  Compiled at Apr  1 2014 14:36:28
  @INC:

/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/perls/perl-5.14.4/lib/site_perl/5.14.4/i686-linux-thread-multi-64int

/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/perls/perl-5.14.4/lib/site_perl/5.14.4

/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/perls/perl-5.14.4/lib/5.14.4/i686-linux-thread-multi-64int

/usr/share/iserv/security/ssh/martin.von.wittich/perl5/perlbrew/perls/perl-5.14.4/lib/5.14.4
.

Bug#743184: Acknowledgement (perl: SpamAssassin spamd segfaults since updating servers to Debian wheezy)

[Martin von Wittich]

OK, I've figured out how to determine what perl has been executing when it 
crashed:

host ~ # for i in /var/crash/0/*perl.core; do echo "p 
my_perl->Icurcop->cop_file\np my_perl->Icurcop->cop_line" | gdb --silent 
/usr/bin/perl $i 2>/dev/null | grep 'gdb'; done
(gdb) $1 = 0xa3887f8 "/usr/share/perl5/Mail/SpamAssassin/Plugin/iXhash.pm"
(gdb) $2 = 75
(gdb) quit
(gdb) $1 = 0xa3887f8 "/usr/share/perl5/Mail/SpamAssassin/Plugin/iXhash.pm"
(gdb) $2 = 75
(gdb) quit
(gdb) $1 = 0xb50f400 "/usr/share/perl5/Mail/SpamAssassin/Plugin/iXhash.pm"
(gdb) $2 = 75
(gdb) quit
(gdb) $1 = 0xb50f400 "/usr/share/perl5/Mail/SpamAssassin/Plugin/iXhash.pm"
(gdb) $2 = 75
(gdb) quit
(gdb) $1 = 0xb084d68 "/usr/share/perl5/Mail/SpamAssassin/Plugin/iXhash.pm"
(gdb) $2 = 75
(gdb) quit
(gdb) $1 = 0x9772fb8 "/usr/share/perl5/Mail/SpamAssassin/Plugin/iXhash.pm"
(gdb) $2 = 75
(gdb) quit
[...]

Apparently all crashes on this machine are caused by that exact location, 
except for a single crash:

(gdb) $1 = 0xc0699b0 "(eval 1231)"
(gdb) $2 = 3325
(gdb) quit

The file ixHash.pm is part of the iXhash SA module[1] that we've packaged 
ourselves. I've published our (probably ancient) version of the file on
paste.debian.net[2]. Unfortunately, line 75 is a huge eval, and I don't know
yet how to pinpoint the exact location in that eval that causes the issue.

[1] http://www.ixhash.net/
[2] http://paste.debian.net/90973/


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

Bug#743889: Postinst doesn't restart Apache

[Martin von Wittich]

Hi,

I just updated my server's libssl1.0.0 package to 1.0.1e-2+deb7u6, and 
the postinst code that restarts the daemons works pretty good:



libssl1.0.0:i386 (1.0.1e-2+deb7u6) wird eingerichtet ...
Checking for services that may need to be restarted...done.
Checking init scripts...
WARNING: init script for postgresql-9.1 not found.

Restarting services possibly affected by the upgrade:
Restarting SpamAssassin Mail Filter Daemon: spamd.
Restarting OpenBSD Secure Shell server: sshd.
Stopping NTP server: ntpd.
Starting NTP server: ntpd.
Stopping FreeRADIUS daemon: freeradius.
Starting FreeRADIUS daemon: freeradius.
Stopping MTA for restart: exim4_listener.
Restarting MTA: exim4.
Restarting Cyrus IMAPd: cyrmaster.
Stopping ClamAV virus database updater: freshclam.
Starting ClamAV virus database updater: freshclam.
Stopping ClamAV daemon: clamd Waiting .  . .
Starting ClamAV daemon: clamd .
Stopping domain name service...: bind9Reloading Squid configuration files.
done.
waiting for pid 12176 to die
.
Starting domain name service...: bind9Reloading Squid configuration files.
done.
.

Services restarted successfully.



Unfortunately though, it overlooked the installed Apache server. I 
believe this is due to the fact that 
/var/lib/dpkg/info/libssl1.0.0:i386.postinst looks for a package 
"apache2-common", but the name is in fact "apache2.2-common":


dev2.iserv.eu ~ # dpkg -S /etc/init.d/apache2
apache2.2-common: /etc/init.d/apache2

There are also a few other package names that seem to be outdated; for 
example, aptitude doesn't find anything for apache-ssl or 
libapache-mod-ssl. The whole list should probably be checked against the 
Debian archive.


Oh, and the postgres init script is called /etc/init.d/postgresql, the 
script seems to be looking for /etc/init.d/postgresql-9.1 and therefore 
can't restart postgres either.


Martin


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

Bug#559537: This bug is a misconfiguration of the server

[Martin von Wittich]

Am 26.11.2012 15:34, schrieb Josip Rodin:

This feature was removed upstream in 2.2.0... I'm not anxious to override
them, so can we close the bug report?


Yes, this can be closed. I changed my configuration to a non-zero 
hashsize and then using SIGHUP as Alan recommended.



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

Bug#655175: rkhunter error message related?

[Martin von Wittich]

We're getting a rkhunter error message on some of our servers; as
/run/initramfs is renamed to /dev/.initramfs in the initramfs init
script, I think this might be related:

[06:25:24]   Checking for hidden files and directories   [ Warning ]
[06:25:24] Warning: Hidden file found: /dev/.initramfs: setuid setgid
sticky directory

The permissions of /dev/.initramfs on the affected server:

root@iserv:~# LANG=C ls -ld /dev/.initramfs/
drwsrwsrwt 2 root root 40 Feb 16 09:16 /dev/.initramfs/

Of our 49 squeeze servers, 2 are affected. None of our 438 lenny servers
are affected, so I'd say this is a) a squeeze bug and b) pretty rare :)

If I can help in any way to track this down, tell me what is should look
for. In the meantime I will configure our rkhunters to ignore
/dev/.initramfs permissions.



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

Bug#681344: postgresql-common: pg_upgradecluster should use pg_ctlcluster stop --force to shut down the cluster

[Martin von Wittich]

Package: postgresql-common
Version: 113
Severity: normal

Currently, pg_upgradecluster uses the following code to shut down the
cluster:

# stopping old cluster, so that we notice early when there are still
# connections
print "Stopping old cluster...\n";
my @argv = ('pg_ctlcluster', $version, $cluster, 'stop', '--', '-t', '5');
error "Could not stop old cluster" if system @argv;

This will cause pg_ctlcluster to shut down the cluster with the "smart"
mode, which will fail after 5 seconds when there are still open
connections to postgres:

Stopping old cluster...
pg_ctl: Server fährt nicht herunter
Error: Could not stop old cluster

pg_upgradecluster should either use --force by default or a parameter
should be added so that users can specify that they want a forced
shutdown.


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

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

Versions of packages postgresql-common depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  debconf [debconf-2.0]  1.5.36.1  Debian configuration management sy
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  postgresql-client-comm 113   manager for multiple PostgreSQL cl
ii  procps 1:3.2.8-9squeeze1 /proc file system utilities
ii  ssl-cert   1.0.28simple debconf wrapper for OpenSSL

postgresql-common recommends no packages.

postgresql-common suggests no packages.

-- debconf information:
* postgresql-common/obsolete-major:
  postgresql-common/untransitioned:



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

Bug#570377: (no subject)

[Martin von Wittich]

Could this be caused by packages that are not marked as automatically
installed? I had this situation on our servers:

# aptitude dist-upgrade -svy > fail.log (see attachedment for output)

After I marked the packages that caused the conflict as automatically
installed:

# aptitude markauto '~nwinst-wnt5-x86-32-driverpack-.*'

And ran the command again:

# aptitude dist-upgrade -svy > success.log (see attachment for output)

aptitude finally did what I expected it to do.

-- 
Mit freundlichen Grüßen,

Martin v. Wittich

IServ GmbH
Rebenring 33
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:martin.von.witt...@iserv.eu
Internet:  iserv.eu

USt.-IdNr.:   DE265149425
Registergericht:  Amtsgericht Braunschweig
Registernummer:   HRB 201822
Geschäftsführer:  Jörg Ludwig

Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Reading task descriptions...
The following NEW packages will be installed:
  winst-driverpack-wnt5-x86-32{ab} 
The following packages will be upgraded:
  iserv-update winst-wnt5-x86-32-driverpack 
2 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1716 MB/1716 MB of archives. After unpacking 6403 MB will be used.
The following packages have unmet dependencies:
  winst-driverpack-wnt5-x86-32: Conflicts: winst-wnt5-x86-32-driverpack-bluetooth but 9.10-1 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-chipset but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-cpu but 10.05-1 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-graphics-a but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-graphics-b but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-graphics-c but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-graphics-languages but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-graphics-physx but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-hid but 12.03 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-lan but 12.05 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-lan-ris but 10.11-1 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-massstorage but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-misc but 12.01 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-modem but 12.05 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-monitor but 10.05-1 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-runtimes but 12.06 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-sound-a but 11.11 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-sound-b but 11.11 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-tv but 10.05-1 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-webcam but 11.07-1 is installed.
Conflicts: winst-wnt5-x86-32-driverpack-wlan but 12.02 is installed.
The following actions will resolve these dependencies:

 Remove the following packages:   
1) iserv-stadt-bs 
2) iserv-stadt-bs-gym 
3) winst-microsoft-windows-xp-pro 
4) winst-wnt5-x86-32-driverpack   

 Keep the following packages at their current version:
5) winst-driverpack-wnt5-x86-32 [Not Installed]   



The following packages will be REMOVED:
  cabextract{u} iserv-stadt-bs{a} iserv-stadt-bs-gym{a} winst-activeperl{u} 
  winst-activepython{u} winst-adobe-flash-player{u} winst-adobe-reader{u} 
  winst-adobe-shockwave-player{u} winst-antolin{u} winst-artrage-starter{u} 
  winst-cccp{u} winst-driverpack-iserv-20110718{u} 
  winst-driverpack-iserv-2011{u} winst-driverpack-iserv-20111222{u} 
  winst-filezilla{u} winst-geogebra{u} winst-ghostscript{u} winst-gimp{u} 
  winst-gsview{u} winst-hot-potatoes{u} winst-inkscape{u} 
  winst-irfanview{u} winst-javaeditor{u} winst-microsoft-windows-xp-pro{a} 
  winst-microsoft-windows-xp-pro-data{u} winst-nero-7-lite{u} winst-nvu{u} 
  winst-openoffice{u} winst-phase5{u} winst-photofiltre{u} winst-putty{u} 
  winst-qt-lite{u} winst-real-alternative-lite{u} winst-scribus{u} 
  winst-smarttech-smart-notebook{u} winst-smarttech-smart-notebook-data{u} 
  winst-smarttech-smart-product-drivers{u} 
  winst-smarttech-

Bug#681344: [Pkg-postgresql-public] Bug#681344: postgresql-common: pg_upgradecluster should use pg_ctlcluster stop --force to shut down the cluster

[Martin von Wittich]

Hi Martin ;)

Am 21.07.2012 17:32, schrieb Martin Pitt:

I don't think it's a good idea. Usually upgrading a DB to a new major
version requires some attention anyway, and should not done with any
level of bruteness.


We upgraded several hundred servers from lenny to squeeze automatically, 
including their postgres databases :)


Admittedly though the databases are rather small, probably none is 
bigger than 1 GB.



or a parameter should be added so that users can specify that they
want a forced shutdown.


That seems okay, but rather redundant. You can always pg_ctlcluster
--force stop the cluster yourself before upgrading. Keeping bug open
to add it to pg_upgradecluster.


I can? AFAIR that didn't work. I can't test it at the moment because I 
don't have a VM with postgres 8.3 ready, but the code seems to agree:


error 'specified cluster is not running' unless $info{'running'};

Martin


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

Bug#687199: vim-runtime: syntax/registry.vim is broken

[Martin von Wittich]

Package: vim-runtime
Version: 2:7.2.445+hg~cb94c42c0e1a-1
Severity: minor

While looking at Windows registry files (*.reg) in vim I noticed that
the highlighting for ft=registry files doesn't seem to work at all. To
reproduce this issue, just create a file "test.reg" with the following
content:

REGEDIT4

; Test

Open it in vim and notice that the comment is not highlighted as such.
A broken regex in syntax/registry.vim seems to be responsible for this issue;
the following patch fixes it for me:

iserv syntax # diff -u  registry.vim.orig registry.vim
--- registry.vim.orig   2012-09-10 20:32:25.0 +0200
+++ registry.vim2012-09-10 20:32:41.0 +0200
@@ -58,7 +58,7 @@
 " Subkey
 syn match  registrySubKey  "^\".*\"="
 " Default value
-syn match  registrySubKey  "^\@="
+"syn match  registrySubKey "^\@="
 
 " Numbers

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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim  2:7.2.445+hg~cb94c42c0e1a-1 Vi IMproved - enhanced vi editor

vim-runtime 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#687411: /etc/cron.daily/spamassassin blocks cron for up to 3600 seconds

[Martin von Wittich]

Package: spamassassin
Version: 3.3.1-1
Severity: wishlist

/etc/cron.daily/spamassassin sleeps for up to 3600 seconds, probably to
distribute the load on SpamAssassin servers when using sa-update:

  # Sleep for up to 3600 seconds
  RANGE=3600
  number=`od -vAn -N2 -tu4 < /dev/urandom`
  number=`expr $number "%" $RANGE`
  sleep $number

  # Update
  umask 022
  sa-update

This has the disadvantage that cron is blocked while the script is
sleeping; it's also annoying when running the script manually.

If this block would be put in a detached subshell:

(
  # Sleep for up to 3600 seconds
  RANGE=3600
  number=`od -vAn -N2 -tu4 < /dev/urandom`
  number=`expr $number "%" $RANGE`
  sleep $number

  # Update
  umask 022
  sa-update
) &

these problems should be resolved.

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

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

Versions of packages spamassassin depends on:
pn  libarchive-tar-perl(no description available)
ii  libdigest-sha1-perl2.13-1NIST SHA-1 message digest algorith
ii  libhtml-parser-perl3.66-1collection of modules that parse H
ii  libnet-dns-perl0.66-2Perform DNS queries from a Perl sc
ii  libnetaddr-ip-perl 4.028+dfsg-1  IP address manipulation module
ii  libsocket6-perl0.23-1Perl extensions for IPv6
ii  libsys-hostname-long-p 1.4-2 Figure out the long (fully-qualifi
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  perl-modules [libio-zl 5.10.1-17squeeze3 Core Perl modules

Versions of packages spamassassin recommends:
ii  gcc4:4.4.5-1 The GNU C compiler
ii  gnupg  1.4.10-4  GNU privacy guard - a free PGP rep
ii  libc6-dev  2.11.3-3  Embedded GNU C Library: Developmen
ii  libio-socket-inet6-per 2.65-1.1  Object interface for AF_INET6 doma
ii  libmail-spf-perl   2.007-1   Perl implementation of Sender Poli
ii  make   3.81-8An utility for Directing compilati
ii  perl [libsys-syslog-pe 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
pn  re2c   (no description available)
ii  spamc  3.3.1-1   Client for SpamAssassin spam filte

Versions of packages spamassassin suggests:
ii  libcompress-zlib-perl  2.024-1   Transitional dummy package for Com
ii  libdbi-perl1.612-1   Perl Database Interface (DBI)
ii  libio-socket-ssl-perl  1.33-1+squeeze1   Perl module implementing object or
ii  libmail-dkim-perl  0.38-1cryptographically identify the sen
pn  libnet-ident-perl  (no description available)
ii  perl [libcompress-zlib 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  pyzor  1:0.5.0-2 spam-catcher using a collaborative
ii  razor  1:2.85-3  spam-catcher using a collaborative

-- Configuration Files:
/etc/default/spamassassin changed [not included]

-- 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#700857: postinst stops nginx instead of restarting it

[Martin von Wittich]

Package: nginx
Version: 0.7.67-3+squeeze3
Severity: normal

Today I had to manually start nginx on our servers because it was no longer
running for some reason. Apparently, there was an update the last night:

> Aptitude 0.6.3: log report
> Mon, Feb 18 2013 04:02:36 +0100
> 
> IMPORTANT: this log only lists intended actions; actions which fail due to
> dpkg problems may not be completed.
> 
> Will install 1 packages, and remove 0 packages.
> 161 kB of disk space will be freed
> ===
> [UPGRADE] nginx 0.7.67-3+squeeze2 -> 0.7.67-3+squeeze3
> ===
> 
> Log complete.

The output from the update:

> Reading package lists...
> Building dependency tree...
> Reading state information...
> Reading extended state information...
> Initializing package states...
> Reading task descriptions...
> The following packages will be upgraded:
>   nginx 
> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 325 kB of archives. After unpacking 161 kB will be freed.
> Writing extended state information...
> Get:1 http://security.debian.org/ squeeze/updates/main nginx amd64 
> 0.7.67-3+squeeze3 [325 kB]
> Reading changelogs...
> Fetched 325 kB in 0s (3019 kB/s)
> (Reading database ... 19466 files and directories currently installed.)
> Preparing to replace nginx 0.7.67-3+squeeze2 (using 
> .../nginx_0.7.67-3+squeeze3_amd64.deb) ...
> Unpacking replacement nginx ...
> Processing triggers for man-db ...
> Setting up nginx (0.7.67-3+squeeze3) ...
> Trying a soft restart
> PID IS RIGHT
> WAITING
> QUIT
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Reading extended state information...
> Initializing package states...
> Reading task descriptions...

It seems like the update should restart nginx, but instead just stopped it.

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

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

Versions of packages nginx depends on:
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libgeoip1 1.4.7~beta6+dfsg-1 A non-DNS IP-to-country resolver l
ii  libpcre3  8.02-1.1   Perl 5 Compatible Regular Expressi
ii  libssl0.9.8   0.9.8o-4squeeze14  SSL shared libraries
ii  lsb-base  3.2-23.2squeeze1   Linux Standard Base 3.2 init scrip
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

nginx recommends no packages.

nginx suggests no packages.

-- Configuration Files:
/etc/nginx/sites-available/default changed:
server {
  listen   80; ## listen for ipv4
  listen   [::]:80 default ipv6only=on; ## listen for ipv6
  server_name  localhost;
  access_log  /var/log/nginx/localhost.access.log;
  gzip_types text/xml application/xml;
  gzip_http_version 1.0;
  gzip_proxied any;
  location /status {
alias   /var/www/status;
  }
}


-- 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#700857: [#ZIH-894-30161]: Re: Bug#700857: postinst stops nginx instead of restarting it

[Martin von Wittich]

Hi Steven,

> That looks like it tried to restart, but may have failed for some
> reason. You may want to check /var/log/nginx/error.log for clues...

The error.log.1 file says:

2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address 
already in use)
[emerg]: bind() to [::]:80 failed (98: Address already in use)
2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address 
already in use)
[emerg]: bind() to [::]:80 failed (98: Address already in use)
2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address 
already in use)
[emerg]: bind() to [::]:80 failed (98: Address already in use)
2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address 
already in use)
[emerg]: bind() to [::]:80 failed (98: Address already in use)
2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address 
already in use)
[emerg]: bind() to [::]:80 failed (98: Address already in use)
2013/02/18 04:02:37 [emerg] 28203#0: still could not bind()
[emerg]: still could not bind()

That correlates with the update. There shouldn't be anything else besides nginx 
that binds to port 80 though, so I'm not sure what could have caused this.


--
Mit freundlichen Grüßen,
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Jörg Ludwig


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

Bug#700857: [#ZIH-894-30161]: Re: Bug#700857: postinst stops nginx instead of restarting it

[Martin von Wittich]

> Get rid of /etc/nginx/sites-enabled/000-default.

I only have default (for contents see the original report):

relay1:/etc/nginx/sites-enabled $ LANG=C ls -l
total 0
lrwxrwxrwx 1 root root 34 Aug 10  2012 default -> 
/etc/nginx/sites-available/default

and that contains my settings.


--
Mit freundlichen Grüßen,
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Jörg Ludwig


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

Bug#521073: (no subject)

[Martin von Wittich]

Binary packages are affected too (Debian lenny):

Get:4 http://update.iserv.eu unstable/non-free
winst-diercke-digitales-handbuch-data 2.0-1.0 [2147MB]
Err http://update.iserv.eu unstable/non-free
winst-diercke-digitales-handbuch-data 2.0-1.0
Error writing to output file - write (27 File too large) [IP:
188.40.93.57 80]
Err http://update.iserv.eu unstable/non-free winst-schroedel-pfadfinder
2.0-1.0
Bad header line [IP: 188.40.93.57 80]
Err http://update.iserv.eu unstable/non-free
winst-diercke-digitales-handbuch 2.0-1.0
Bad header line [IP: 188.40.93.57 80]

I believe the limit are 2^31-1 bytes. A 2123001900 byte file in our repo
works, a 2488475395 byte file does not. We stumble over this problem
regularly because we are using APT to distribute Windows programs onto
our software deployment servers, and those programs can be quite big.



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

Bug#720556: libjs-jquery-ui: i18n *.js files are not provided as minified files

[Martin von Wittich]

Package: libjs-jquery-ui
Version: 1.10.1+dfsg-1
Severity: normal

Upstream provides minified versions of the files in /ui/i18n/*.js (in
the folder /ui/minified/i18n, though that's probably not important to
us anyway). The Debian package unfortunately does not, because the
following command in debian/rules skips over these files:

override_dh_auto_build:
for file in `find development-bundle/ui/jquery* -name '*.js'`; do \
yui-compressor $$file -o $${file%.js}.min.js; \
done
[...]

I propose to change the find command to this:

  find development-bundle/ui/ -name '*.js'

which would minify the i18n files too (but nothing else) so that
software that relies on the minified versions to exist will work.


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

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

Versions of packages libjs-jquery-ui depends on:
ii  libjs-jquery  1.10.2-1   JavaScript library for dynamic web

Versions of packages libjs-jquery-ui recommends:
ii  javascript-common 7  Base support for javascript librar

Versions of packages libjs-jquery-ui suggests:
ii  libjs-jquery-ui-docs   1.10.1+dfsg-1 Documentation for JQuery-UI

-- 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#635340: clamav: "LibClamAV Error: Opcode 20 of type 0 is not implemented yet!" error messages

[Martin von Wittich]

Package: clamav
Version: 0.97.1+dfsg-1~lenny1
Severity: normal

Since July 15th we are getting error messages like the following from
our Debian servers that are running clamscan:

LibClamAV Error: Opcode 20 of type 0 is not implemented yet!
LibClamAV Warning: Bytecode 2 failed to run: Invalid argument passed to
function

One of the files causing this error seems to be the IE8 executable:

iserv ~/Martin # md5sum iexplore.exe 
b602d63ce41cb8c487fcfbb6419e  iexplore.exe
iserv ~/Martin # clamscan -v iexplore.exe 
Scanning iexplore.exe
LibClamAV Error: Opcode 20 of type 0 is not implemented yet!
LibClamAV Warning: Bytecode 14 failed to run: Invalid argument passed to
function
iexplore.exe: OK

--- SCAN SUMMARY ---
Known viruses: 1006625
Engine version: 0.97.1
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.61 MB
Data read: 0.61 MB (ratio 1.01:1)
Time: 5.911 sec (0 m 5 s)

Unfortunately I don't know whether I'm allowed to attach this file
(copyright?).

Just a few days earlier there was an update so I guess this might be
related:

Aptitude 0.4.11.11: log report
Sun, Jul 10 2011 03:29:37 +0200

IMPORTANT: this log only lists intended actions; actions which fail due
to dpkg problems may not be completed.

Will install 5 packages, and remove 0 packages.
2154kB of disk space will be used
===
[UPGRADE] clamav 0.97+dfsg-2~lenny1 -> 0.97.1+dfsg-1~lenny1
[UPGRADE] clamav-base 0.97+dfsg-2~lenny1 -> 0.97.1+dfsg-1~lenny1
[UPGRADE] clamav-daemon 0.97+dfsg-2~lenny1 -> 0.97.1+dfsg-1~lenny1
[UPGRADE] clamav-freshclam 0.97+dfsg-2~lenny1 -> 0.97.1+dfsg-1~lenny1
[UPGRADE] libclamav6 0.97+dfsg-2~lenny1 -> 0.97.1+dfsg-1~lenny1
===

Log complete.


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
ExtendedDetectionInfo = "yes"
PidFile = "/var/run/clamav/clamd.pid"
TemporaryDirectory = "/tmp"
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "10485760"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
VirusEvent disabled
ExitOnOOM disabled
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
AllowSupplementaryGroups = "yes"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
AlgorithmicDetection = "yes"
ScanPE = "yes"
ScanELF = "yes"
DetectBrokenExecutables disabled
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
PhishingAlwaysBlockCloak disabled
PhishingAlwaysBlockSSLMismatch disabled
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
OLE2BlockMacros disabled
ScanPDF = "yes"
ScanArchive = "yes"
ArchiveBlockEncrypted disabled
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
ClamukoScanOnAccess disabled
ClamukoScannerCount = "3"
ClamukoScanOnOpen disabled
ClamukoScanOnClose disabled
ClamukoScanOnExec disabled
ClamukoIncludePath disabled
ClamukoExcludePath disabled
ClamukoExcludeUID disabled
ClamukoMaxFileSize = "5242880"
DevACOnly disabled
DevACDepth disabled
DevLiblog disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
PidFile = "/var/run/clamav/freshclam.pid"
DatabaseDirectory = "/var/lib/clamav/"
Foreground disabled
Debug disabled
AllowSupplementaryGroups disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "12"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
MaxAttempts = "3"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyCl

Bug#559537: Found in 2.1.10+dfsg-2~bpo50+1

[Martin von Wittich]

We're seeing freeradius segfaults on 14 of our servers. I was able to
reproduce the issue with a VM by flooding the server with requests from
JRadius; when I did a backtrace with gdb, I got the following output:

iserv:~# gdb freeradius
GNU gdb 6.8-debian
Copyright (C) 2008 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 "i486-linux-gnu"...
(gdb) set args -f
(gdb) run
Starting program: /usr/sbin/freeradius -f
[Thread debugging using libthread_db enabled]
[New Thread 0xb74056b0 (LWP 15647)]
[New Thread 0xb73b2b90 (LWP 15650)]
[New Thread 0xb6bb1b90 (LWP 15651)]
[New Thread 0xb63b0b90 (LWP 15652)]
[New Thread 0xb5bafb90 (LWP 15653)]
[New Thread 0xb53aeb90 (LWP 15654)]
[New Thread 0xb4badb90 (LWP 15667)]
[New Thread 0xb43acb90 (LWP 15668)]
[New Thread 0xb3babb90 (LWP 15669)]
[New Thread 0xb31ffb90 (LWP 15670)]
[New Thread 0xb29feb90 (LWP 15671)]
[New Thread 0xb21fdb90 (LWP 15672)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb43acb90 (LWP 15668)]
0xb748b942 in _IO_un_link () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0  0xb748b942 in _IO_un_link () from /lib/i686/cmov/libc.so.6
#1  0xb747e3c0 in fclose () from /lib/i686/cmov/libc.so.6
#2  0xb73bae26 in get_next (name=0xb43a9b7c "martin", ht=0x8faa940) at
rlm_passwd.c:288
#3  0xb73bb08b in passwd_map (instance=0x8faa730, request=0x907e7b0) at
rlm_passwd.c:541
#4  0x0806427c in modcall (component=1, c=0x8fa8d10, request=0x907e7b0)
at modcall.c:297
#5  0x08060bdb in indexed_modcall (comp=1, idx=0, request=0x907e7b0) at
modules.c:728
#6  0x0806102c in module_authorize (autz_type=0, request=0x907e7b0) at
modules.c:1494
#7  0x0804f28f in rad_authenticate (request=0x907e7b0) at auth.c:567
#8  0xb73c6789 in eappeap_process (handler=0x90b3270,
tls_session=0x8fea5b8) at peap.c:973
#9  0xb73c50e7 in eappeap_authenticate (arg=0x8fa8ac0,
handler=0x90b3270) at rlm_eap_peap.c:260
#10 0xb73dae69 in eaptype_call (atype=0x8fa7a00, handler=0x90b3270) at
eap.c:174
#11 0xb73db91d in eaptype_select (inst=0x8f9acc8, handler=0x90b3270) at
eap.c:409
#12 0xb73d9e19 in eap_authenticate (instance=0x8f9acc8,
request=0xb32c1410) at rlm_eap.c:319
#13 0x0806427c in modcall (component=0, c=0x8fac2c0, request=0xb32c1410)
at modcall.c:297
#14 0x08060bdb in indexed_modcall (comp=0, idx=6, request=0xb32c1410) at
modules.c:728
#15 0x08060fec in module_authenticate (auth_type=6, request=0xb32c1410)
at modules.c:1502
#16 0x0804f964 in rad_authenticate (request=0xb32c1410) at auth.c:373
#17 0x080701d4 in radius_handle_request (request=0xb32c1410,
fun=0x804efb0 ) at event.c:3774
#18 0x08067868 in request_handler_thread (arg=0x8ffbe70) at threads.c:525
#19 0xb77584c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#20 0xb750084e in clone () from /lib/i686/cmov/libc.so.6
(gdb)

I believe that matches this bug, therefore I reopened it.

-- System Information:
Debian Release: 5.0.9
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages freeradius depends on:
ii  adduser3.110 add and remove users and groups
ii  ca-certificates20080809  Common CA certificates
ii  freeradius-common  2.1.10+dfsg-2~bpo50+1 FreeRADIUS common files
ii  libc6  2.7-18lenny7  GNU C Library: Shared libraries
ii  libfreeradius2 2.1.10+dfsg-2~bpo50+1 FreeRADIUS shared library
ii  libgdbm3   1.8.3-3   GNU dbm database routines
(runtime
ii  libltdl7   2.2.6b-2~bpo50+1  A system independent dlopen
wrappe
ii  libpam0g   1.0.1-5+lenny1Pluggable Authentication
Modules l
ii  libperl5.105.10.0-19lenny5   Shared Perl library
ii  libssl0.9.80.9.8g-15+lenny14 SSL shared libraries
ii  lsb-base   3.2-20Linux Standard Base 3.2
init scrip
ii  python2.5  2.5.2-15+lenny1   An interactive high-level
object-o
ii  ssl-cert   1.0.23simple debconf wrapper for
OpenSSL

Versions of packages freeradius recommends:
ii  freeradius-utils   2.1.10+dfsg-2~bpo50+1 FreeRADIUS client utilities

Versions of packages freeradius suggests:
pn  freeradius-krb5(no description



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

Bug#651430: dpkg: silence --force-confmiss warning

[Martin von Wittich]

Package: dpkg
Version: 1.15.8.11
Severity: wishlist

When dpkg is forced to re-create deleted conffiles with the
--force-confmiss option, it prints the following warning for each
missing conffile:


Configuration file `%s', does not exist on system.
Installing new config file as you requested.

Since we are managing our configuration files with a custom script, we
have configured dpkg on all our servers to use --force-confmiss by
default - we want dpkg to always give us the package manager defaults,
and our script then takes care of modifications and deletions. The
warning message is pretty annoying in this configuration - e.g. when we
install acpi-support, we get over 500 lines of warnings that only
obscure the important messages.

A switch to disable this warning would therefore be very nice.

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

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

Versions of packages dpkg depends on:
ii  coreutils   8.5-1GNU core utilities
ii  libbz2-1.0  1.0.5-6  high-quality block-sorting file co
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libselinux1 2.0.96-1 SELinux runtime shared libraries
ii  xz-utils5.0.0-2  XZ-format compression utilities
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt0.8.10.3+squeeze1 Advanced front-end for dpkg

-- 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#650149: Patch

[Martin von Wittich]

Tags: Patch

I've fixed this bug in our simple-cdd installation. Patch is appended.

-- 
Mit freundlichen GrÌßen,

Martin v. Wittich

IServ GmbH
Rebenring 33
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:martin.von.witt...@iserv.eu
Internet:  iserv.eu

USt.-IdNr.:   DE265149425
Registergericht:  Amtsgericht Braunschweig
Registernummer:   HRB 201822
GeschÀftsfÌhrer:  Jörg Ludwig
--- /usr/share/simple-cdd/tools/build/debian-cd.orig	2010-06-20 10:15:56.0 +0200
+++ /usr/share/simple-cdd/tools/build/debian-cd	2012-06-07 02:33:20.0 +0200
@@ -161,9 +161,22 @@
 make image CD=1
 
 if [ -x /usr/bin/edos-debcheck ]; then
-# check for missing dependencies with edos-debcheck, ignoring debian-installer files which are a little unusual
-for p in $(find $TDIR/$CODENAME/CD1/dists/ -name Packages | egrep -v debian-installer) ; do
-echo "checking for missing dependencies with edos-debcheck: $p"
-edos-debcheck -failures -explain < $p
-done
+# check for missing dependencies with edos-debcheck, ignoring
+# debian-installer files which are a little unusual
+(
+  cd "$TDIR/$CODENAME/CD1/dists"
+
+  # create a list of architectures, e.g. binary-i386, binary-amd64
+  find . -regex './[^/]*/[^/]*/debian-installer' -prune -o \( \
+  -name Packages -print \) | awk -F '/' '{print $4}' | sort | uniq | \
+  # loop through these architectures
+  while read i
+  do
+# pipe all Packages files that belong to the current architecture
+# to edos-debcheck
+echo "Checking $i:"
+find . -regex "./[^/]*/[^/]*/$i/.*" -name Packages \
+-exec cat {} \; | edos-debcheck -failures -explain
+  done
+)
 fi

Bug#646024: imvirt reports Xen as VirtualPC Virtual Machine

[Martin von Wittich]

Package: imvirt
Version: 0.9.1-1
Severity: normal

I'm working on a customer server that I believe to be virtualized with Xen:

iserv:~# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] 
(rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 SCSI storage controller: XenSource, Inc. Xen Platform Device (rev 01)
00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 20)
00:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 20)

iserv:~# dmesg|grep -i xen
[0.00] ACPI: RSDP 000EA010, 0024 (r2Xen)
[0.00] ACPI: XSDT 3F4F7F90, 003C (r1Xen  HVM0 HVML  
  0)
[0.00] ACPI: FACP 3F4F7DE0, 00F4 (r4Xen  HVM0 HVML  
  0)
[0.00] ACPI: DSDT 3F4F6C40, 1116 (r2Xen  HVM0 INTL 
20060707)
[0.00] ACPI: APIC 3F4F7EE0, 0070 (r2Xen  HVM0 HVML  
  0)
[0.00] ACPI: HPET 3F4F7F50, 0038 (r1Xen  HVM0 HVML  
  0)

iserv:~# dmidecode |grep -i xen
Vendor: Xen
Manufacturer: Xen
Manufacturer: Xen
String 1: Xen

But imvirt 0.3.1+svn426-1~bpo50+1 reported "Virtual Machine", and after I've 
upgraded it to imvirt 0.9.1-1, it now reports "VirtualPC Virtual Machine":

iserv:~# imvirt -d
   ImVirt::VMD::QEMU: detect()
ImVirt::Utils::dmidecode::kernel: sysfs_isdir('class/dmi/id') = 1
ImVirt::Utils::dmidecode::kernel: reading '/sys/class/dmi/id/bios_vendor'
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |QEMU)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |QEMU)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |QEMU)
 ImVirt::VMD::OpenVZ: detect()
  ImVirt: dec_pts(HASH(0x8cd97a8), 3, Virtual, |OpenVZ)
ImVirt::VMD::Xen: detect()
ImVirt::Utils::dmidecode::kernel: sysfs_isdir('class/dmi/id') = 1
ImVirt::Utils::dmidecode::kernel: reading '/sys/class/dmi/id/bios_vendor'
  ImVirt: inc_pts(HASH(0x8cd97a8), 6, Virtual, |Xen)
  ImVirt: dec_pts(HASH(0x8cd97a8), 3, Virtual, |Xen, PV)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |Xen)
  ImVirt: dec_pts(HASH(0x8cd97a8), 3, Virtual, |Xen, PV)
  ImVirt: dec_pts(HASH(0x8cd97a8), 3, Virtual, |Xen, PV)
ImVirt::VMD::PillBox: detect()
  ImVirt: inc_pts(HASH(0x8cd97a8), 3, Virtual)
  ImVirt: inc_pts(HASH(0x8cd97a8), 1, Virtual, |VMware)
  ImVirt: inc_pts(HASH(0x8cd97a8), 1, Virtual, |VMware)
  ImVirt::VMD::VirtualPC: detect()
ImVirt::Utils::dmidecode::kernel: sysfs_isdir('class/dmi/id') = 1
ImVirt::Utils::dmidecode::kernel: reading '/sys/class/dmi/id/product_name'
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VirtualPC)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VirtualPC)
  ImVirt: inc_pts(HASH(0x8cd97a8), 6, Virtual, |VirtualPC, 
Virtual, Machine)
 ImVirt::VMD::VMware: detect()
ImVirt::Utils::dmidecode::kernel: sysfs_isdir('class/dmi/id') = 1
ImVirt::Utils::dmidecode::kernel: reading '/sys/class/dmi/id/product_name'
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VMware)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VMware)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VMware)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VMware)
 ImVirt::VMD::lguest: detect()
ImVirt::VMD::UML: detect()
  ImVirt: dec_pts(HASH(0x8cd97a8), 1, Virtual, |UML)
ImVirt::VMD::KVM: detect()
ImVirt::Utils::dmidecode::kernel: sysfs_isdir('class/dmi/id') = 1
ImVirt::Utils::dmidecode::kernel: reading '/sys/class/dmi/id/product_name'
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |KVM)
ImVirt::Utils::dmidecode::kernel: sysfs_isdir('class/dmi/id') = 1
ImVirt::Utils::dmidecode::kernel: reading '/sys/class/dmi/id/bios_vendor'
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |KVM)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |KVM)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |KVM)
ImVirt::VMD::Generic: detect()
  ImVirt: inc_pts(HASH(0x8cd97a8), 24, Virtual)
  ImVirt: inc_pts(HASH(0x8cd97a8), 3, Virtual)
 ImVirt::VMD::VirtualBox: detect()
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VirtualBox)
  ImVirt: dec_pts(HASH(0x8cd97a8), 6, Virtual, |VirtualBox)
$VAR1 = {
  'Physical' => '0.04',
  'VirtualPC Virtual Machine' => '0.96'
};


-- S

Bug#646916: dmidecode prints everything twice

[Martin von Wittich]

Package: dmidecode
Version: 2.9-1.2
Severity: normal

dmidecode prints everything twice:

root@iserv:~# dmidecode -t chassis
# dmidecode 2.9
SMBIOS 2.6 present.

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: To Be Filled By O.E.M.
Type: Desktop
Lock: Not Present
Version: To Be Filled By O.E.M.
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

SMBIOS 2.6 present.

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: To Be Filled By O.E.M.
Type: Desktop
Lock: Not Present
Version: To Be Filled By O.E.M.
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

I used the "dmidecode -t chassis" output as an example because it is the
shortest, but this bug affects all types and also occurs when no type is
specified. Everything from the second "SMBIOS 2.6 present" on is redundant.
This bug only occurs on our Squeeze servers, lenny is not affected.


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

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

Versions of packages dmidecode depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

dmidecode recommends no packages.

dmidecode 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#796102: imvirt: /usr/lib/imvirt/xen hangs forever

[Martin von Wittich]

Package: imvirt
Version: 0.9.4-4
Severity: important

Dear Maintainer,

we have a server where imvirt (or actually the helper tool
/usr/lib/imvirt/xen) will hang forever with 99% CPU usage:

server ~ # strace /usr/lib/imvirt/xen
execve("/usr/lib/imvirt/xen", ["/usr/lib/imvirt/xen"], [/* 31 vars */]) = 0
brk(0)  = 0x7f9f5c7d5000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9f5c175000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26297, ...}) = 0
mmap(NULL, 26297, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9f5c168000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\357\1\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1599504, ...}) = 0
mmap(NULL, 3713080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f9f5b9b8000
mprotect(0x7f9f5bb39000, 2097152, PROT_NONE) = 0
mmap(0x7f9f5bd39000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x181000) = 0x7f9f5bd39000
mmap(0x7f9f5bd3e000, 18488, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f9f5bd3e000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9f5c174000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9f5c173000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9f5c17
arch_prctl(ARCH_SET_FS, 0x7f9f5c173700) = 0
mprotect(0x7f9f5bd39000, 16384, PROT_READ) = 0
mprotect(0x7f9f5c171000, 4096, PROT_READ) = 0
mprotect(0x7f9f5bf67000, 4096, PROT_READ) = 0
munmap(0x7f9f5c168000, 26297)   = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f9f5c1739d0) = 8114
wait4(8114, 

The server seems to be running in a VirtualBox VM. From dmidecode:

Handle 0x0002, DMI type 11, 7 bytes
OEM Strings
String 1: vboxVer_5.0.0
String 2: vboxRev_101573

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

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages imvirt depends on:
ii  libimvirt-perl  0.9.4-4
ii  perl5.14.2-21+deb7u2

imvirt recommends no packages.

imvirt suggests no packages.

-- no debconf information

Bug#712839: sudo: /var/lib/sudo permissions

[Martin von Wittich]

Hi,

I'm wondering about this too. I've looked into the postinst; it creates
/var/lib/sudo, but it doesn't set any explicit permissions and instead
just copies the old ones from /var/run/sudo:

> # handle state directory transition from /var/run/sudo to /var/lib/sudo,
> # moving any existing content over to avoid re-lecturing existing users
> if [ -d "/var/run/sudo" ];then
> mkdir -p /var/lib/sudo
> (cd /var/run/sudo ; tar cf - .) | (cd /var/lib/sudo ; tar xf -)
> rm -rf /var/run/sudo
> fi

According to man sudoers, both 700 and 755 are wrong and it should be 711:

>  unable to open /var/lib/sudo/ts/username
>sudoers was unable to read or create the user's time stamp file.  This
>can happen when timestampowner is set to a user other than root and the
>mode on /var/lib/sudo is not searchable by group or other.  The default
>mode for /var/lib/sudo is 0711.

When I delete /var/lib/sudo and then use sudo, it recreates the
directory with 711. Seems to me like a bug in the postinst; I think it
should just execute `chmod 711 /var/lib/sudo` whenever it runs.

-- 
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#857023: durep -hs 1G does not work due to bug in processSizeOption

[Martin von Wittich]

Package: durep
Version: 0.9-3
Severity: normal
Tags: patch upstream

Dear Maintainer,

"durep -hs 1G" does not work as expected, though the documentation says
it should:

dev2.iserv.eu ~ # durep --help | grep hide-size
  -hs, --hide-size=N[bkmg]  do not display entries using N Bytes/Kb/Mb/Gb

For example in this folder, durep -hs 1G will list both bigfile (as expected)
but also smallfile:

dev2.iserv.eu ~/test # ll
total 1.1G
-rw-r--r-- 1 root root 1.0G Mar  7 10:46 bigfile
-rw-r--r-- 1 root root 1.0M Mar  7 10:46 smallfile

dev2.iserv.eu ~/test # durep -hs 1G .
[ /var/lib/iserv/remote-support/iserv-martin.von.wittich/test 1.0G (2 
files, 0 dirs) ]
   1.0G [# ]  99.90% bigfile
   1.0M [  ]   0.10% smallfile

The cause is a bug in the processSizeOption function in the durep code. The
code to handle gigabyte sizes is there, but it is never reached:

  if(defined $temp) {
if($temp =~ m/^[kK]/) {
  return $size * 1024;
}
elsif ($temp =~ m/^[mM]/) {
  return $size * 1048576;
}
elsif ($temp =~ m/^[mM]/) {
  return $size * 1048576 * 1024;
}
return $size;
  }

I've attached a patch that fixes this. The fixed durep behaves as expected:

dev2.iserv.eu ~/test # ~/durep.fixed -hs 1G .
[ /var/lib/iserv/remote-support/iserv-martin.von.wittich/test 1.0G (2 
files, 0 dirs) ]
   1.0G [# ]  99.90% bigfile

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages durep depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  perl   5.20.2-3+deb8u6

Versions of packages durep recommends:
ii  libmldbm-perl  2.05-1

durep suggests no packages.

-- debconf information:
  durep/makereports: false
  durep/filesystems: .
* durep/httpfileroot:
--- /usr/bin/durep	2014-08-02 11:19:05.0 +0200
+++ durep.fixed	2017-03-07 10:43:16.631568385 +0100
@@ -375,7 +375,7 @@
 elsif ($temp =~ m/^[mM]/) {
   return $size * 1048576;
 }
-elsif ($temp =~ m/^[mM]/) {
+elsif ($temp =~ m/^[gG]/) {
   return $size * 1048576 * 1024;
 }
 return $size;

Bug#826553: libpam-duo: No IPv6 support in libpam-duo 1.9.11

[Martin von Wittich]

Package: libpam-duo
Version: 1.9.11-1
Severity: normal
Tags: ipv6

Dear Maintainer,

I'm trying to use libpam-duo on a server that has only IPv6
connectivity. Our authentication server has both IPv4 and IPv6
addresses:

xenh4:~# host auth.iserv.eu
auth.iserv.eu has address 88.198.205.8
auth.iserv.eu has IPv6 address 2a01:4f8:162:1247::108

Unfortunately, libpam-duo seems to ignore the IPv6 and always tries to
connect via IPv4:

xenh4:~# tshark -i eth0 -f "host auth.iserv.eu"

Capturing on 'eth0'
  1   0.00  0.0.0.0 -> 88.198.205.8 TCP 74 49087→443 [SYN] Seq=0 
Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874590986 TSecr=0 WS=64
  2   0.997362  0.0.0.0 -> 88.198.205.8 TCP 74 [TCP Retransmission] 
49087→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874591236 
TSecr=0 WS=64
  3   3.001370  0.0.0.0 -> 88.198.205.8 TCP 74 [TCP Retransmission] 
49087→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874591737 
TSecr=0 WS=64
  4   7.013370  0.0.0.0 -> 88.198.205.8 TCP 74 [TCP Retransmission] 
49087→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874592740 
TSecr=0 WS=64
  5  11.020794  0.0.0.0 -> 88.198.205.8 TCP 74 49088→443 [SYN] Seq=0 
Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874593741 TSecr=0 WS=64
  6  12.017353  0.0.0.0 -> 88.198.205.8 TCP 74 [TCP Retransmission] 
49088→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874593991 
TSecr=0 WS=64
  7  14.021371  0.0.0.0 -> 88.198.205.8 TCP 74 [TCP Retransmission] 
49088→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874594492 
TSecr=0 WS=64
  8  18.029369  0.0.0.0 -> 88.198.205.8 TCP 74 [TCP Retransmission] 
49088→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2874595494 
TSecr=0 WS=64

According to https://duo.com/docs/duounix-notes , IPv6 support was only
added in duo_unix-1.9.12 - September 2014:

* Include https_timeout configuration parameter
* IPv6 support on systems that have getaddrinfo

Could the package be updated so that IPv6 support works?

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-duo depends on:
ii  libc6  2.19-18+deb8u4
ii  libduo31.9.11-1
ii  libpam-runtime 1.1.8-3.1+deb8u1
ii  libpam0g   1.1.8-3.1+deb8u1+b1
ii  libssl1.0.01.0.1t-1+deb8u2
ii  multiarch-support  2.19-18+deb8u4

libpam-duo recommends no packages.

libpam-duo suggests no packages.

-- Configuration Files:
/etc/security/pam_duo.conf changed [not included]

-- no debconf information

Bug#826578: hw-detect: check-missing-firmware ignores symlinked firmware packages

[Martin von Wittich]

Package: hw-detect
Severity: important
Tags: d-i patch

Dear Maintainer,

we are distributing our system with a custom Debian installer that has
been created with simple-cdd and contains non-free firmware packages.
One of our customers has reported back to us that he encountered an
error message during the installation that the following firmware file
couldn't be found:

rtl_nic/rtl8168e-3.fw

I checked our installer source and determined that we do supply a
firmware-realtek package that contains this firmware file:

server /root/install-jessie-new/add/firmware # dpkg-deb -c 
firmware-realtek_0.43_all.deb | grep rtl8168e-3
-rw-r--r-- root/root  3872 2014-06-16 01:51 
./lib/firmware/rtl_nic/rtl8168e-3.fw

Then I booted the installer in a VM and looked in /cdrom/firmware. Most of the
firmware packages there were files, but some were symlinks, including
the firmware-realtek package:

root@unassigned:/cdrom/firmware# find . -type l -exec ls -l {} \;
lr-xr-xr-x 1 root root 62 May 19  2016 ./firmware-bnx2_0.43_all.deb -> 
../pool/non-free/f/firmware-nonfree/firmware-bnx2_0.43_all.deb
lr-xr-xr-x 1 root root 60 May 19  2016 ./firmware-linux-free_3.3_all.deb -> 
../pool/main/f/firmware-free/firmware-linux-free_3.3_all.deb
lr-xr-xr-x 1 root root 71 May 19  2016 ./firmware-linux-nonfree_0.43_all.deb -> 
../pool/non-free/f/firmware-nonfree/firmware-linux-nonfree_0.43_all.deb
lr-xr-xr-x 1 root root 65 May 19  2016 ./firmware-realtek_0.43_all.deb -> 
../pool/non-free/f/firmware-nonfree/firmware-realtek_0.43_all.deb

I believe that the Debian installer build process automatically replaces
firmware files with symlinks to the pool if it determines those files to be
identical. To ensure that this not a problem caused by simple-cdd, I booted the
current Debian netinst that I downloaded here:

http://cdimage.debian.org/debian-cd/8.5.0/amd64/iso-cd/debian-8.5.0-amd64-netinst.iso

There was only a single file located in /cdrom/firmware, but it was also a
symlink:

/cdrom/firmware/firmware-linux-free-3.3_all.deb -> 
../pool/main/f/firmware-free/firmware-linux-free-3.3_all.deb

So apparently it's not caused by simple-cdd.

I then figured out that the installer uses a script called
check-missing-firmware to load firmware; apparently it determines
missing firmware files and looks amongst others in /cdrom/firmware for
firmware packages which might provide these files. Unfortunately, the
code only accepts packages that are real files, not symlinks; notice the
[ -f ... ] in line 238 in the function check_for_firmware:

check_for_firmware() {
  echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
  for filename in $@; do
if [ -f "$filename" ]; then
  if check_deb_arch "$filename" && list_deb_firmware "$filename" | grep -qf 
/tmp/grepfor; then
log "installing firmware package $filename"
install_firmware_pkg "$filename" || true
  fi
fi
  done
  rm -f /tmp/grepfor
}

I think that this is a bug and it is responsible for the firmware our
customer reported. I've marked this bug as important because I believe
it has a major impact on the correct operation of this script. Attached
is a simple patch that replaces the `-f` with `-e`, which should fix
this problem.

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- check-missing-firmware.sh.orig	2012-06-15 07:56:09.0 +0200
+++ check-missing-firmware.sh	2016-06-06 16:41:44.985996412 +0200
@@ -235,7 +235,7 @@
 check_for_firmware() {
 	echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
 	for filename in $@; do
-		if [ -f "$filename" ]; then
+		if [ -e "$filename" ]; then
 			if check_deb_arch "$filename" && list_deb_firmware "$filename" | grep -qf /tmp/grepfor; then
 log "installing firmware package $filename"
 install_firmware_pkg "$filename" || true

Bug#776391: [CVE-2015-0235]: heap-based buffer overflow in __nss_hostname_digits_dots()

[Martin von Wittich]

The libc update unfortunately failed to restart the affected services
because the postinst only does that when updating from a version < 2.13:

/var/lib/dpkg/info/libc6:i386.postinst:
142:if dpkg --compare-versions "$preversion" lt 2.13; then

Could this be changed so that this update restarts most of the affected
services?

-- 
Mit freundlichen Grüßen,
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig


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

Bug#791554: mdadm: checkarray ionice/renice errors when md check is too fast

[Martin von Wittich]

Package: mdadm
Version: 3.2.5-5
Severity: minor
Tags: patch

Dear Maintainer,

we have set up some of our servers with a small MD raidi1 consisting only
of one device, so we may later add an additional hard drive without
having to re-create the filesystem. On these servers, we sometimes get
checkarray error mails:

> Subject: Cron  if [ -x /usr/share/mdadm/checkarray ] && [ $(date 
> +%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
> From: Cron Daemon 
> To: root@backup.hostname
> Date: So, 05.07.2015 00:57
> 
> renice: failed to get priority for 17571 (process ID): No such process

Apparently the md check runs so fast that when the scripts wants to renice it,
the process is no longer running. I've attached a patch that resolves the issue
by redirecting STDERR of renice/ionice to /dev/null.

-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root
ARRAY /dev/md/0 metadata=1.2 UUID=9e1e626b:660983fa:7c7743ce:a611dca9 
name=unassigned:0

--- /etc/default/mdadm
INITRDSTART='all'
AUTOSTART=true
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid1] 
md0 : active raid1 sda2[0]
  9992064 blocks super 1.2 [1/1] [U]
  
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   80  976762584 sda
   81   1024 sda1
   82   1384 sda2
   83  966759424 sda3
  1101048575 sr0
   909992064 md0

--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=489087,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=392936k,mode=755)
/dev/disk/by-uuid/97c2159e-276d-42c7-b34b-9352e17ae2c7 on / type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=785860k)

--- initrd.img-3.16.0-0.bpo.4-amd64:
90542 blocks
5279b5dc98152be1e8305bc59a037166  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/multipath.ko
4801fcd2b248deea3e66b4f16c5252c9  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/raid1.ko
fda057547b8af02ae5fb8b042f0b0e7b  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/dm-mod.ko
7d40ea67702e1dc0f9dc80f0072e30ce  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/linear.ko
933c1955c35bbc2036c95687767c235a  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/raid0.ko
86dbe96964776a439910fd34fe011ec1  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/md-mod.ko
72a2cdad3802be27c53b929a87cd4448  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/raid456.ko
c404c37b621ecc8039a167249f65835c  
./lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/md/raid10.ko
a560b1c713f6f2bf42abcd9dade35d6a  ./scripts/local-top/mdadm
cd4e75e3374c6a6564ba77d48b90fc6a  ./sbin/mdadm
60596c5613c3a565c95f4fd8e639a902  ./etc/mdadm/mdadm.conf
4cfabdc50bcde6e16ba134109db9b816  ./conf/mdadm

--- initrd's /conf/conf.d/md:
no conf/md file.

--- /proc/modules:
raid1 34596 1 - Live 0xa00cf000
md_mod 111686 2 raid1, Live 0xa019b000

--- /var/log/syslog:

--- volume detail:
/dev/sda:
   MBR Magic : aa55
Partition[0] : 2048 sectors at 2048 (type 83)
Partition[1] : 2768 sectors at 4096 (type fd)
Partition[2] :   1933518848 sectors at 20004864 (type 83)
--
/dev/sda1 is not recognised by mdadm.
/dev/sda2:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
 Array UUID : 9e1e626b:660983fa:7c7743ce:a611dca9
   Name : unassigned:0
  Creation Time : Sat Mar 14 16:10:53 2015
 Raid Level : raid1
   Raid Devices : 1

 Avail Dev Size : 19984384 (9.53 GiB 10.23 GB)
 Array Size : 9992064 (9.53 GiB 10.23 GB)
  Used Dev Size : 19984128 (9.53 GiB 10.23 GB)
Data Offset : 16384 sectors
   Super Offset : 8 sectors
  State : clean
Device UUID : 057439bf:ad946a16:6911d6b1:da8a3d59

Update Time : Mon Jul  6 08:51:24 2015
   Checksum : 26aa75e8 - correct
 Events : 71


   Device Role : Active device 0
   Array State : A ('A' == active, '.' == missing)
--
/dev/sda3 is not recognised by mdadm.

--- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16.0-0.bpo.4-amd64 
root=UUID=97c2159e-276d-42c7-b34b-9352e17ae2c7 ro quiet

--- grub2:
insmod raid
set root='(mduuid/9e1e626b660983fa7c7743cea611dca9)'
linux   /boot/vmlinuz-3.16.0-0.bpo.4-amd64 
root=UUID=97c2159e-276d-42c7-b34b-9352e17ae2c7 ro  quiet
insmod raid
set root='(mduuid/9e1e626b660983fa7c7743cea611dca9)'
linux   /boot/vmlinuz-3.16.0-0.bpo.4-amd64 
root=UUID=97c2159e-276d-42c7-b34b-9352e17ae2c7 ro

Bug#761209: squid3: init script fails to parse an indented cache_dir directive

[Martin von Wittich]

Package: squid3
Version: 3.1.20-2.2+deb7u2
Severity: normal
Tags: patch

Dear Maintainer,

the squid3 init script fails to parse the cache_dir directive from our
squid3.conf. The reason is that our cache_dir directive is indented with
two spaces:

  cache_dir ufs /var/spool/squid3 1 16 256

The sed expression that parses the config file doesn't allow for leading
white space:

s/^'$1'['"$w"']\+ ...

^ matches the beginning of the string and $1 matches cache_dir, and so
the expression will only parse lines that directly begin with cache_dir.

This prevents the init script from populating the cache dir; the
administrator has to resolve this by manually running squid3 -z. If the
cache dir is not populated, squid3 won't start and will instead log the
following error to cache.log:

2014/09/11 18:50:46| /var/spool/squid3/00: (2) No such file or directory
FATAL:  Failed to verify one of the swap directories, Check cache.log
for details.  Run 'squid -z' to create swap directories
if needed, or if running Squid for the first time.
Squid Cache (Version 3.1.20): Terminated abnormally.


I've attached a patch that fixes the following issues:
- consistent tab indentions in the init script
- fixes the w= line in find_cache_dir that is apparently supposed to
  contain a space followed by a tab, but currently just contains five
  spaces.
- allows for spaces before cache_dir in both find_cache_dir and
  find_cache_type.

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.14-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages squid3 depends on:
ii  adduser   3.113+nmu3
ii  libc6 2.13-38+deb7u4
ii  libcap2   1:2.22-1.2
ii  libcomerr21.42.5-1.1
ii  libdb5.1  5.1.29-5
ii  libexpat1 2.1.0-1+deb7u1
ii  libgcc1   1:4.7.2-5
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u2
ii  libk5crypto3  1.10.1+dfsg-5+deb7u2
ii  libkrb5-3 1.10.1+dfsg-5+deb7u2
ii  libldap-2.4-2 2.4.31-1+nmu2
ii  libltdl7  2.4.2-1.1
ii  libpam0g  1.1.3-7.1
ii  libsasl2-22.1.25.dfsg1-6+deb7u1
ii  libstdc++64.7.2-5
ii  libxml2   2.8.0+dfsg1-7+wheezy1
ii  logrotate 3.8.1-4
ii  lsb-base  4.1+Debian8+deb7u1
ii  netbase   5.0
ii  squid3-common 3.1.20-2.2+deb7u2

squid3 recommends no packages.

Versions of packages squid3 suggests:
ii  resolvconf   1.67
ii  smbclient2:3.6.19-1~bpo70+1
pn  squid-cgi
ii  squidclient  3.1.20-2.2+deb7u2
pn  ufw  

-- Configuration Files:
/etc/logrotate.d/squid3 changed:
/var/log/squid3/*.log {
daily
compress
delaycompress
rotate 7
missingok
nocreate
sharedscripts
prerotate
/usr/lib/iserv/botdetector $1
endscript
postrotate
test ! -e /var/run/squid3.pid || /usr/sbin/squid3 -k rotate
endscript
}

/etc/squid3/squid.conf changed:
  http_port 10.0.0.13:3128 intercept
  http_port 127.0.0.1:3128
  cache_dir ufs /var/spool/squid3 1 16 256
  maximum_object_size 1 GB


-- no debconf information
--- squid3.orig	2014-09-11 18:56:59.946223957 +0200
+++ squid3	2014-09-11 19:06:28.736129772 +0200
@@ -33,20 +33,20 @@
 ulimit -n 65535
 
 find_cache_dir () {
-w=" " # space tab
-res=`sed -ne '
-s/^'$1'['"$w"']\+[^'"$w"']\+['"$w"']\+\([^'"$w"']\+\).*$/\1/p;
-t end;
-d;
-:end q' < $CONFIG`
-[ -n "$res" ] || res=$2
-echo "$res"
+	w=" 	" # space tab
+	res=`sed -ne '
+		s/^['"$w"']\+'$1'['"$w"']\+[^'"$w"']\+['"$w"']\+\([^'"$w"']\+\).*$/\1/p;
+		t end;
+		d;
+		:end q' < $CONFIG`
+	[ -n "$res" ] || res=$2
+	echo "$res"
 }
 
 find_cache_type () {
 	w=" 	" # space tab
 	res=`sed -ne '
-		s/^'$1'['"$w"']\+\([^'"$w"']\+\).*$/\1/p;
+		s/^['"$w"']\+'$1'['"$w"']\+\([^'"$w"']\+\).*$/\1/p;
 		t end;
 		d;
 		:end q' < $CONFIG`
@@ -59,8 +59,8 @@
 	cache_type=`find_cache_type cache_dir`
 
 	#
-# Create spool dirs if they don't exist.
-#
+	# Create spool dirs if they don't exist.
+	#
 	if [ "$cache_type" = "coss" -a -d "$cache_dir" -a ! -f "$cache_dir/stripe" ] || [ "$cache_type" != "coss" -a -d "$cache_dir" -a ! -d "$cache_dir/00" ]
 	then
 		log_warning_msg "Creating $DESC cache structure"
@@ -106,7 +106,7 @@
 }
 
 case "$1" in
-start)
+	start)
 	log_daemon_msg "Starting $DESC" "$NAME"
 	if start ; then
 		log_end_msg $?
@@ -114,7 +114,7 @@
 		log_end_msg $?
 	fi
 	;;
-stop)
+	stop)
 	log_daemon_msg "Stopping $DESC" "$NAME"
 	if stop ; then
 		log_end_msg $?
@@ -122,13 +122,13 @@
 		log_end_msg $?
 	fi
 	;;
-reload|force-reload)
+	reload|force-reload)
 	log_action_msg "Reloading $DESC configuration files"
 	start-stop-da

Bug#762184: cups error_log fills hard disk

[Martin von Wittich]

Package: cups
Version: 1.5.3-5+deb7u4
Severity: normal

Dear Maintainer,

in the last week I've had two of our servers fill up the hard disk with
errors in the cups error_log:

host ~/var-log-cups # ll
total 308G
-rw-r- 1 root adm 285G Sep 19 11:50 error_log
-rw-r- 1 root adm 3.6G Sep 19 00:00 error_log.1.gz
-rw-r- 1 root adm 3.4G Sep 18 00:00 error_log.2.gz
-rw-r- 1 root adm 3.5G Sep 17 00:00 error_log.3.gz
-rw-r- 1 root adm 3.5G Sep 16 00:00 error_log.4.gz
-rw-r- 1 root adm 3.6G Sep 15 00:00 error_log.5.gz
-rw-r- 1 root adm 3.6G Sep 14 00:00 error_log.6.gz
-rw-r- 1 root adm 2.2G Sep 13 00:00 error_log.7.gz

host ~/var-log-cups # head -n 1 error_log | tail
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:43
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:64
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:65
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:66
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:67
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:68
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:69
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:70
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:71
E [19/Sep/2014:00:08:26 +0200] [Job 3972] Illegal output call of P2PObject:72
host ~/var-log-cups # head -n 10 error_log |  grep -v 'Illegal output' | wc 
-l
113
host ~/var-log-cups # head -n 10 error_log |  grep 'Illegal output' | wc -l
99887

I haven't been able to figure out the root cause of this issue yet, but I
think the fact that CUPS is filling up the hard disk with logs is a bug on its
own which should be prevented somehow.

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

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

Versions of packages cups depends on:
ii  adduser3.113+nmu3
ii  bc 1.06.95-2+b1
ii  cups-client1.5.3-5+deb7u4
ii  cups-common1.5.3-5+deb7u4
ii  cups-filters   1.0.18-2.1+deb7u1
ii  cups-ppdc  1.5.3-5+deb7u4
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.15
ii  ghostscript9.05~dfsg-6.3+deb7u1
ii  libavahi-client3   0.6.31-2
ii  libavahi-common3   0.6.31-2
ii  libc-bin   2.13-38+deb7u4
ii  libc6  2.13-38+deb7u4
ii  libcups2   1.5.3-5+deb7u4
ii  libcupscgi11.5.3-5+deb7u4
ii  libcupsimage2  1.5.3-5+deb7u4
ii  libcupsmime1   1.5.3-5+deb7u4
ii  libcupsppdc1   1.5.3-5+deb7u4
ii  libdbus-1-31.6.8-1+deb7u4
ii  libgcc11:4.7.2-5
ii  libgnutls262.12.20-8+deb7u2
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u2
ii  libkrb5-3  1.10.1+dfsg-5+deb7u2
ii  libldap-2.4-2  2.4.31-1+nmu2
ii  libpam0g   1.1.3-7.1
ii  libpaper1  1.1.24+nmu2
ii  libslp11.2.1-9
ii  libstdc++6 4.7.2-5
ii  libusb-1.0-0   2:1.0.11-1
ii  lsb-base   4.1+Debian8+deb7u1
ii  poppler-utils  0.18.4-6
ii  procps 1:3.3.3-3
ii  ssl-cert   1.0.32

Versions of packages cups recommends:
ii  avahi-daemon   0.6.31-2
pn  colord 
ii  foomatic-filters   4.0.17-1
ii  ghostscript-cups   9.05~dfsg-6.3+deb7u1
pn  printer-driver-gutenprint  

Versions of packages cups suggests:
ii  cups-bsd   1.5.3-5+deb7u4
pn  cups-pdf   
ii  foomatic-db20120523-1
pn  hplip  
pn  printer-driver-hpcups  
ii  smbclient  2:3.6.19-1~bpo70+1
ii  udev   175-7.2

-- Configuration Files:
/etc/cups/cups-files.conf changed:
SystemGroup admins
AccessLog /var/log/cups/access_log
ErrorLog /var/log/cups/error_log
PageLog /var/log/cups/page_log


-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, ipp14, lpd, socket, usb, snmp, dnssd


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

Bug#766326: squid3: squid crashes: assertion failed: MemBuf.cc:280: "size < capacity"

[Martin von Wittich]

Package: squid3
Version: 3.1.20-2.2+deb7u2
Severity: normal

Dear Maintainer,

on one of our servers, squid3 is crashing regularly with the following
error message:

host ~ # zgrep -i fail /var/log/squid3/cache.log*
/var/log/squid3/cache.log:2014/10/22 07:38:30| assertion failed: MemBuf.cc:280: 
"size < capacity"
/var/log/squid3/cache.log.2.gz:2014/10/20 10:55:00| assertion failed: 
MemBuf.cc:280: "size < capacity"
/var/log/squid3/cache.log.2.gz:2014/10/20 16:29:07| assertion failed: 
MemBuf.cc:280: "size < capacity"
/var/log/squid3/cache.log.5.gz:2014/10/17 10:37:40| assertion failed: 
MemBuf.cc:280: "size < capacity"
/var/log/squid3/cache.log.5.gz:2014/10/17 14:46:58| assertion failed: 
MemBuf.cc:280: "size < capacity"

I believe this is the following upstream bug which has since been fixed
upstream:

http://bugs.squid-cache.org/show_bug.cgi?id=3869

Would it be possible to apply this patch to the Debian package?

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages squid3 depends on:
ii  adduser   3.113+nmu3
ii  libc6 2.13-38+deb7u6
ii  libcap2   1:2.22-1.2
ii  libcomerr21.42.5-1.1
ii  libdb5.1  5.1.29-5
ii  libexpat1 2.1.0-1+deb7u1
ii  libgcc1   1:4.7.2-5
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u2
ii  libk5crypto3  1.10.1+dfsg-5+deb7u2
ii  libkrb5-3 1.10.1+dfsg-5+deb7u2
ii  libldap-2.4-2 2.4.31-1+nmu2
ii  libltdl7  2.4.2-1.1
ii  libpam0g  1.1.3-7.1
ii  libsasl2-22.1.25.dfsg1-6+deb7u1
ii  libstdc++64.7.2-5
ii  libxml2   2.8.0+dfsg1-7+wheezy1
ii  logrotate 3.8.1-4
ii  lsb-base  4.1+Debian8+deb7u1
ii  netbase   5.0
ii  squid3-common 3.1.20-2.2+deb7u2

squid3 recommends no packages.

Versions of packages squid3 suggests:
ii  resolvconf   1.67
ii  smbclient2:3.6.19-1~bpo70+1
pn  squid-cgi
pn  squidclient  
pn  ufw  


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

Bug#846052: passenger-config/status cannot find instance registry

[Martin von Wittich]

On Mon, 28 Nov 2016 07:40:10 + Matijs van Zuijlen 
 wrote:

I have just upgraded to passenger 5, and now I want to restart my
application the 'new' way by using passenger-config. I have tried this
both through capistrano, and on the command line, and I get the
following error message:

   *** ERROR: Phusion Passenger doesn't seem to be running. If you are sure 
that it
  is running, then the causes of this problem could be one of:


I just upgraded our Redmine installation to Debian stretch, and I have 
the same issue. I believe this is caused by the PrivateTmp feature of 
systemd (PrivateTmp=true is set in /lib/systemd/system/apache2.service), 
because while passenger-status is looking in /tmp, Apache is storing the 
instance registry dir in /tmp/systemd-private-...:


redmine.iserv.eu ~ # ll 
/tmp/systemd-private-df0217594fc94127b16c17b45a99716c-apache2.service-Q1WevN/tmp

total 72K
drwxr-xr-x 3 www-data www-data 4.0K Aug 15 18:49 bundler/
drwxr-xr-x 4 root root 4.0K Aug 15 18:49 passenger.U9uCrRI/
-rw--- 1 www-data www-data0 Aug 15 18:52 
RackMultipart20170815-1192-8063mg
-rw--- 1 www-data www-data0 Aug 15 18:56 
RackMultipart20170815-1192-8qsxi
-rw--- 1 www-data www-data0 Aug 15 18:53 
RackMultipart20170815-1192-v5lfb6

-rw--- 1 root root  30K Aug 15 18:56 passenger-error-24wMBJ.html
-rw--- 1 root root  30K Aug 15 18:49 passenger-error-GwQoka.html

I have resolved this as follows:

1) Create 
/etc/systemd/system/apache2.service.d/passenger-instance-reg.conf with 
the following contents:


[Service]
ExecStartPre=/bin/mkdir -p /run/passenger
ExecStopPost=/bin/rmdir --ignore-fail-on-non-empty /run/passenger

2) systemctl daemon-reload

3) Add the following to your Apache configuration:

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846052
PassengerInstanceRegistryDir /run/passenger

4) Add the following to your /etc/environment:

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846052
PASSENGER_INSTANCE_REGISTRY_DIR=/run/passenger

5) restart Apache and reconnect (SSH) or re-login (local). Opening a new 
shell is not enough, because /etc/environment is only read by PAM. 
passenger-status should work now.


--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#875802: (no subject)

[Martin von Wittich]

--- /var/lib/iserv/remote-support/iserv-martin.von.wittich/src2/psmisc-22.21/src/fuser.c	2017-09-14 16:55:21.0 +0200
+++ /var/lib/iserv/remote-support/iserv-martin.von.wittich/src/psmisc-22.21/src/fuser.c	2017-09-14 16:57:15.808933238 +0200
@@ -59,7 +59,7 @@
 #include "signals.h"
 #include "i18n.h"
 
-//#define DEBUG 1
+#define DEBUG 1
 
 #define NAME_FIELD 20		/* space reserved for file name */
 /* Function defines */
@@ -504,6 +504,11 @@
 	for (sun_tmp = sun_head; sun_tmp != NULL; sun_tmp = sun_tmp->next) {
 		if (sun_tmp->dev == this_name->st.st_dev
 		&& sun_tmp->inode == this_name->st.st_ino) {
+#ifdef DEBUG
+			printf("adding socket %s %lX %lX\n", this_name->filename,
+			   (unsigned long)net_dev,
+			   (unsigned long)sun_tmp->net_inode);
+#endif/* DEBUG */
 			add_inode(ino_list, this_name, net_dev,
   sun_tmp->net_inode);
 			return 0;
@@ -1555,7 +1560,7 @@
 {
 	FILE *fp;
 	char line[BUFSIZ];
-	int scanned_inode;
+	ino_t scanned_inode;
 	struct stat st;
 	struct unixsocket_list *newsocket;
 
@@ -1567,7 +1572,7 @@
 	while (fgets(line, BUFSIZ, fp) != NULL) {
 		char *path;
 		char *scanned_path = NULL;
-		if (sscanf(line, "%*x: %*x %*x %*x %*x %*d %d %as",
+		if (sscanf(line, "%*x: %*x %*x %*x %*x %*d %lld %as",
 			   &scanned_inode, &scanned_path) != 2) {
 			if (scanned_path)
 free(scanned_path);
@@ -1576,6 +1581,9 @@
 		if (scanned_path == NULL)
 			continue;
 		path = scanned_path;
+#ifdef DEBUG
+		fprintf(stderr, "fill_unix_cache: scanned_inode:%lld scanned_path:%s\n", scanned_inode, scanned_path);
+#endif/* DEBUG */
 		if (*scanned_path == '@')
 			scanned_path++;
 		if (timeout(stat, scanned_path, &st, 5) < 0) {

Bug#876373: reportbug: endless loop when specifiying package "linux"

[Martin von Wittich]

Package: reportbug
Version: 7.1.7
Severity: normal

Dear Maintainer,

I wanted to report a kernel bug, and tried to specify "linux" as a
package (I since figured out that I need to run `reportbug kernel`
instead). This causes an endless loop:


host ~ # reportbug -u text linux
Running 'reportbug' as root is probably insecure! Continue [y|N|q|?]? y
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: us-ascii
Please change your locale if this is incorrect.

Using 'root ' as your from address.
Getting status for linux...
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
^C
reportbug: exiting due to user interrupt.


This issue is reproducible both on jessie and stretch, though only the stretch
reportbug will print the "E: No packages found" message.


-- Package-specific info:
** Environment settings:
EDITOR="vim"
VISUAL="vim"
DEBEMAIL="Martin von Wittich "
INTERFACE="urwid"

** /var/lib/iserv/remote-support/iserv-martin.von.wittich/.reportbugrc:
reportbug_version "7.1.7"
mode standard
ui urwid
no-check-uid

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4.7
ii  python33.5.3-1
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.2.2
pn  dlocate
ii  emacs24-bin-common 24.5+1-11+deb9u1
ii  exim4  4.89-2+deb9u1
ii  exim4-daemon-heavy [mail-transport-agent]  4.89-2+deb9u1
ii  file   1:5.30-1+deb9u1
pn  gir1.2-gtk-3.0 
pn  gir1.2-vte-2.91
ii  gnupg  2.1.18-6
pn  python3-gi 
pn  python3-gi-cairo   
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4.7
ii  file   1:5.30-1+deb9u1
ii  python33.5.3-1
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed:
submit
query-bts
cc
config-files
compress
ui urwid
verify


-- no debconf information

Bug#876372: reportbug: -u should say why a certain user interface is not available

[Martin von Wittich]

Package: reportbug
Version: 7.1.7
Severity: wishlist

Dear Maintainer,

I just install reportbug on a Debian stretch machine with the following
command:

# aptitude install reportbug python-urwid

Our default APT configuration won't install Recommends or Suggests, so
I manually specified python-urwid because I knew that I had to install
the package manually to get the urwid UI to work.

But when I tried to report a bug, reportbug would silently ignore the
"ui urwid" setting I put into the /etc/reportbug.conf. Therefore I tried
to specifiy the UI manually:

host ~ # EDITOR=vim DEBEMAIL="Martin von Wittich " 
reportbug  -u urwid
Ignored bogus setting for -u: urwid
...

This left me pretty confused, because I though I had the correct package
installed. I looked into the code, and even in /usr/lib/python3/
dist-packages/reportbug/ui/urwid_ui.py the exception message says:

raise UINotImportable('Please install the python-urwid package to
use this interface.')

(This exception message is never visible anywhere though, because
ui/__init__.py always tries to load all UIs and will therefore silently
discard any exceptions.)

It took me a while to figure out that reportbug now uses Python 3, and
that I therefore had to install python3-urwid (though admittedly the
package Suggests the correct urwid package; if I had looked there, I
might have noticed sooner). Apparently the exception message just hasn't
been updated accordingly.

It would be nice if reportbug could be a bit more helpful in this
situation. Maybe a specific `ui` setting or `-u` invocation should
cause it to try to load the respective UI package again, and this time
it should print the exception message before falling back to the text
UI?

-- Package-specific info:
** Environment settings:
EDITOR="vim"
VISUAL="vim"
DEBEMAIL="Martin von Wittich "
INTERFACE="urwid"

** /var/lib/iserv/remote-support/iserv-martin.von.wittich/.reportbugrc:
reportbug_version "7.1.7"
mode standard
ui urwid
no-check-uid

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4.7
ii  python33.5.3-1
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.2.2
pn  dlocate
ii  emacs24-bin-common 24.5+1-11+deb9u1
ii  exim4  4.89-2+deb9u1
ii  exim4-daemon-heavy [mail-transport-agent]  4.89-2+deb9u1
ii  file   1:5.30-1+deb9u1
pn  gir1.2-gtk-3.0 
pn  gir1.2-vte-2.91
ii  gnupg  2.1.18-6
pn  python3-gi 
pn  python3-gi-cairo   
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4.7
ii  file   1:5.30-1+deb9u1
ii  python33.5.3-1
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- Configuration Files:
/etc/reportbug.conf changed:
submit
query-bts
cc
config-files
compress
ui urwid
verify


-- no debconf information

Bug#876381: linux-image-4.9.0-3-amd64: fanotify doesn't see events from other namespaces

[Martin von Wittich]

Package: src:linux
Version: 4.9.30-2+deb9u5
Severity: normal
Tags: upstream

Dear Maintainer,

we use the Linux fanotify interface in a virus scanner to detect
viruses as soon as the files are written. Yesterday we noticed that a
machine that has been upgraded to Debian stretch no longer detects
viruses that have been uploaded with a PHP script served by Apache.

The issue is easily reproducable by installing the package fnotifystat
and using that to monitor for filesystem events caused by Apache, for
example:

# fnotifystat -v | grep apache

Then request some document served by Apache, or just trigger a reload:

# systemctl reload apache2

fnotifystat won't print any filesystem events caused by Apache, the only
thing you'll see are a few events from apachectl that is used by systemd
to reload Apache.

The reason for this is apparently the namespace isolation done by
systemd that is triggered by the following setting:

host ~ # grep PrivateTmp /lib/systemd/system/apache2.service 
PrivateTmp=true

If I comment the PrivateTmp line out and then restart Apache:

# systemctl daemon-reload; systemctl restart apache2

then fnotifystat will be able to see events caused by Apache, either
from requesting a document, or from reloading it. This issue has been
documented on some websites already, but I haven't found any bugreports
for it yet:

https://community.sophos.com/kb/en-us/122625
https://lkml.org/lkml/2015/10/29/268
https://community.f-secure.com/t5/Business/Linux-Security-11-00-unable-to/ta-p/77793

It is easily worked around by disabling PrivateTmp on all services that
may be used to upload files, but I do believe that it should be properly
fixed in the kernel. fanotify seems to be the intended interface for
virus scanners, and therefore it shouldn't be accidentally circumvented
by namespace isolation.

-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

** Command line:
root=UUID=97174b79-e90a-436b-b6b8-55f37167c1e5 ro  quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information

** Loaded modules:
dm_mod
cpuid
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xt_NFLOG
xt_REDIRECT
nf_nat_redirect
ipt_REJECT
nf_reject_ipv4
xt_mac
xt_u32
xt_length
xt_nat
iptable_nat
nf_nat_ipv4
veth
xt_multiport
nf_conntrack_ipv4
nf_defrag_ipv4
xt_TCPMSS
nf_nat_tftp
xt_conntrack
nf_conntrack_tftp
nf_nat_sip
nf_conntrack_sip
nf_nat_pptp
nf_nat_proto_gre
nf_conntrack_pptp
nf_conntrack_proto_gre
xt_tcpudp
nf_nat_irc
iptable_filter
bridge
nf_conntrack_irc
stp
llc
nf_nat_h323
nf_conntrack_netlink
nf_conntrack_h323
xfrm_user
nf_nat_ftp
xfrm_algo
nf_conntrack_ftp
nf_nat_amanda
ts_kmp
nf_conntrack_amanda
nf_nat
nf_conntrack
overlay
nfnetlink_log
nfnetlink
intel_rapl
x86_pkg_temp_thermal
coretemp
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
evdev
pcspkr
intel_rapl_perf
loop
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
fscrypto
ecb
mbcache
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
crc32c_intel
xen_netfront
xen_blkfront
aesni_intel
aes_x86_64
glue_helper
lrw
gf128mul
ablk_helper
cryptd

** PCI devices:

** USB devices:
not available


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.9.0-3-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-3-amd64 recommends:
ii  firmware-linux-free  3.4
pn  irqbalance   

Versions of packages linux-image-4.9.0-3-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-3-amd64 is related to:
ii  firmware-amd-graphics 20161130-3
pn  firmware-atheros  
ii  firmware-bnx2 20161130-3
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20161130-3
ii  firmware-misc-nonfree 20161130-3
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20161130-3
pn  firmware-samsung  
pn  firmware-siano

Bug#847928: libxml2: sporadic "Unimplemented block at ../../xmlschemas.c:27279" errors

[Martin von Wittich]

Package: libxml2
Version: 2.9.1+dfsg1-5+deb8u3
Severity: normal
Tags: upstream

Dear Maintainer,

I'm trying to validate the grammar.xml of LanguageTool with xmlstarlet:

https://github.com/languagetool-org/languagetool/blob/master/languagetool-language-modules/de/src/main/resources/org/languagetool/rules/de/grammar.xml

This works, but xmlstarlet often prints "Unimplemented block" error
messages that seem to originate from libxml2:

www0.iserv.eu ~ # xmlstarlet val --err -s 
/opt/LanguageTool/org/languagetool/rules/rules.xsd 
/opt/LanguageTool/org/languagetool/rules/de/grammar.xml 2>&1 | tail
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
/opt/LanguageTool/org/languagetool/rules/de/grammar.xml:28343.17: Element 
'rule': Character content other than whitespace is not allowed because the 
content type is 'element-only'.
/opt/LanguageTool/org/languagetool/rules/de/grammar.xml:28343.29: Element 
'invalid-tag': This element is not expected. Expected is ( example ).
/opt/LanguageTool/org/languagetool/rules/de/grammar.xml - invalid

I've reduced the grammar.xml to a minimal working example that still
triggers the issue, and I'll attach it along with the necessary *.xsd
files so the issue can be reproduced. The error doesn't occur every
time, but is still easily reproducable by running the command multiple
times:

www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
www0.iserv.eu ~ # xmlstarlet val -q --err -s rules.xsd grammar.xml
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279
Unimplemented block at ../../xmlschemas.c:27279

I believe the bug corresponds to this upsteam bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=723607

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libxml2 depends on:
ii  libc6  2.19-18+deb8u6
ii  liblzma5   5.1.1alpha+20120614-2+b3
ii  multiarch-support  2.19-18+deb8u6
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libxml2 recommends:
ii  xml-core  0.13+nmu2

libxml2 suggests no packages.

-- no debconf information


grammar.xml
Description: XML document


pattern.xsd
Description: XML document


rules.xsd
Description: XML document

Bug#833147: hddtemp misinterpretes CHECK POWER MODE result and erroneously believes disk is sleeping

[Martin von Wittich]

Package: hddtemp
Version: 0.3-beta15-52
Severity: normal

Dear Maintainer,

we have a server with the following disk:

=== START OF INFORMATION SECTION ===
Model Family: Seagate Constellation ES (SATA 6Gb/s)
Device Model: ST500NM0011
Serial Number:Z1M0BZRA
LU WWN Device Id: 5 000c50 0404c7128
Firmware Version: SN02
User Capacity:500,107,862,016 bytes [500 GB]
Sector Size:  512 bytes logical/physical
Rotation Rate:7202 rpm
Form Factor:  3.5 inches
Device is:In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:Mon Aug  1 13:17:08 2016 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

When trying to read the temperature of this disk with hddtemp, it sometimes
reports the correct temperature, and sometimes erroneously reports that the
disk is sleeping:

server ~ # hddtemp -uC /dev/sda
/dev/sda: ST500NM0011: drive is sleeping
server ~ # hddtemp -uC /dev/sda
/dev/sda: ST500NM0011: 27 C

Apparently it misdetects the power mode, and so does hdparm -C:

server ~ # hdparm -C /dev/sda
/dev/sda:
 drive state is:  active/idle

server ~ # hdparm -C /dev/sda
/dev/sda:
 drive state is:  unknown

I figured out what exactly was going on with hdparm --verbose -C:

server ~ # hdparm --verbose -C /dev/sda

/dev/sda:
outgoing cdb:  85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: sb[]:  72 01 00 1d 00 00 00 0e 09 0c 00 00 00 ff 00 00 00 00 00 00 40 50 
00 00 00 00 00 00 00 00 00 00
SG_IO: desc[]:  09 0c 00 00 00 ff 00 00 00 00 00 00 40 50
  ATA_16 stat=50 err=00 nsect=ff lbal=00 lbam=00 lbah=00 dev=40
 drive state is:  active/idle

server ~ # hdparm --verbose -C /dev/sda

/dev/sda:
outgoing cdb:  85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: sb[]:  72 01 00 1d 00 00 00 0e 09 0c 00 00 00 81 00 00 00 00 00 00 40 50 
00 00 00 00 00 00 00 00 00 00
SG_IO: desc[]:  09 0c 00 00 00 81 00 00 00 00 00 00 40 50
  ATA_16 stat=50 err=00 nsect=81 lbal=00 lbam=00 lbah=00 dev=40
 drive state is:  unknown

Note the 0xFF in the output where hdparm reports active/idle, and the 0x81 in
the output where it reports unknown.

I looked into the source code of hdparm and hddtemp and figured out that both
seem to be using the ATA command CHECK POWER MODE (0xE5), which probably
corresponds to the 0xE5 0x00 bytes and the end of "outgoing cdb". I've found a
spec PDF (though I don't know whether this is the correct one, I'm pretty new
to ATA specs), and it documents 0x81 as follows:

http://www.t13.org/Documents/UploadedDocuments/docs2013/d2161r5-ATAATAPI_Command_Set_-_3.pdf

page 344

81h Device is in the PM1:Idle state, the EPC feature set is enable, and the 
device is in the
Idle_a power condition (see 4.9.2).

hddtemp (and hdparm too, but that is a different bug report) should probably be
adapted so they'll understand these new output codes.

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hddtemp depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u4
ii  lsb-base   4.1+Debian13+nmu1

hddtemp recommends no packages.

Versions of packages hddtemp suggests:
pn  ksensors  

-- debconf information excluded

Bug#824207: ghostscript: Segmentation fault when printing in color mode

[Martin von Wittich]

I've got the same bug here:

> dev2.iserv.eu ~ # gdb --args gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH 
> -sOutputFile=test.ps -sDEVICE=png16m -r72 -dLastPage=1 2010-2-op.pdf 
> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
> Copyright (C) 2014 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 "i586-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 gs...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH 
> -sOutputFile=test.ps -sDEVICE=png16m -r72 -dLastPage=1 2010-2-op.pdf
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> __lll_unlock_elision (lock=lock@entry=0x8260f94, private=0) at 
> ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> 29  ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: Datei oder 
> Verzeichnis nicht gefunden.
> (gdb) bt
> #0  __lll_unlock_elision (lock=lock@entry=0x8260f94, private=0) at 
> ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> #1  0xf7123ec0 in __pthread_mutex_unlock_usercnt (mutex=0x8260f94, 
> decr=) at pthread_mutex_unlock.c:66
> #2  0xf761d3b4 in pthread_mutex_unlock (mutex=0x8260f94) at forward.c:194
> #3  0xf788b5ea in gp_monitor_leave () from /usr/lib/libgs.so.9
> #4  0xf784073c in gsicc_get_link_profile () from /usr/lib/libgs.so.9
> #5  0xf7840c05 in gsicc_get_link () from /usr/lib/libgs.so.9
> #6  0xf783b9e2 in ?? () from /usr/lib/libgs.so.9
> #7  0xf79f3bfb in gx_image_enum_begin () from /usr/lib/libgs.so.9
> #8  0xf79eef21 in gx_begin_image1 () from /usr/lib/libgs.so.9
> #9  0xf7a125ef in gx_default_begin_typed_image () from /usr/lib/libgs.so.9
> #10 0xf782d1f2 in ?? () from /usr/lib/libgs.so.9
> #11 0xf7a12559 in gx_default_begin_image () from /usr/lib/libgs.so.9
> #12 0xf7a12649 in gx_default_begin_typed_image () from /usr/lib/libgs.so.9
> #13 0xf782d1f2 in ?? () from /usr/lib/libgs.so.9
> #14 0xf79b263b in gs_image_begin_typed () from /usr/lib/libgs.so.9
> #15 0xf77d9967 in zimage_setup () from /usr/lib/libgs.so.9
> #16 0xf77d9fc0 in image1_setup () from /usr/lib/libgs.so.9
> #17 0xf77da0fa in ?? () from /usr/lib/libgs.so.9
> #18 0xf77a4fc4 in ?? () from /usr/lib/libgs.so.9
> #19 0xf77a69c2 in gs_interpret () from /usr/lib/libgs.so.9
> #20 0xf779b34c in gs_main_run_string_end () from /usr/lib/libgs.so.9
> #21 0xf779b3dc in gs_main_run_string_with_length () from /usr/lib/libgs.so.9
> #22 0xf779b423 in gs_main_run_string () from /usr/lib/libgs.so.9
> #23 0xf779c924 in ?? () from /usr/lib/libgs.so.9
> #24 0xf779caaf in ?? () from /usr/lib/libgs.so.9
> #25 0xf779cd23 in ?? () from /usr/lib/libgs.so.9
> #26 0xf779e09b in gs_main_init_with_args () from /usr/lib/libgs.so.9
> #27 0xf779ef52 in gsapi_init_with_args () from /usr/lib/libgs.so.9
> #28 0x080487c3 in main ()

The upstream bug contains a patch but it doesn't look like it's possible
to apply this to the ghostscript 9.05 package. Maybe we could get an
update or a backport to ghostscript 9.19 from stretch?

-- 
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[Martin von Wittich]

Any update on this? Debian 8.5 has been released in June, but we're
still seeing this bug on our VMs.

-- 
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[Martin von Wittich]

Hi Michael,

> I pulled the patch mentioned in this bug report into our jessie branch
> [1]. This means it will be part of the next stable release which is
> scheduled for the upcoming 8.6 point release.
> 
> I created debs which you can get from [2]. I versioned them so that the
> package will nicely upgrade once the final 215-17+deb8u5 reaches the
> stable archive.
> It would be great if you install and test those packages and report back.

Thanks! I've installed the new systemd packages on 10 of our 12 development 
VMs; I couldn't install them on the other two because those are i386. If you 
could provide i386 builds, I'll install them on those machines too.

It didn't take longer than a day for that issue to occur on at least one 
machine, so testing this shouldn't take too long. I've set up reminders on 
Wednesday and Friday so that I won't forget to report back.

Martin

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[Martin von Wittich]

a domino effect to the 
remaining ones because the host CPUs were completely overloaded, and now 
there are no longer enough vulnerable VMs to set it off reliably?


There are still "BUG: soft lockup" messages on some VMs, but these 
almost all occured at pretty much exactly 0:00 o'clock, which is the 
time when logrotate runs on our servers (we like our logs to begin and 
end at 0:00 o'clock exactly), so I suppose the host CPU is just 
overburdened when all these rotations and daemon restarts happen at the 
exact same time.


I haven't gotten any reports from my colleagues of any other issues 
since I upgraded most of the machines to systemd 
215-17+deb8u5~1.gbp51d6e1, so I'd say so far it's looking pretty good. I 
will post new results on Friday.


--
Mit freundlichen Grüßen,
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[Martin von Wittich]

Hi,

the promised update (I know, I'm a little late):

I ran the following two commands on all the servers I listed in my 
previous mail to count the amount of "BUG" and "Looping too fast" 
messages in the past 5 days:


zgrep Loop 
/var/log/syslog{-20160714.gz,-20160715.gz,-20160716.gz,-20160717,} | wc -l
zgrep BUG 
/var/log/syslog{-20160714.gz,-20160715.gz,-20160716.gz,-20160717,} | wc -l


I've counted a grand total of 0 "BUG" and 0 "Looping too fast" (I made 
sure that my grep commands actually work by replacing the pattern with 
"." because I thought I was doing something wrong ^^).


No complaints from our developers either, and all VMs have an uptime of 
at least 5 days, so apparently there haven't been any unexpected or 
desperate reboots. I also looked into htop on each machine; no systemd 
process was hogging the CPU, and used CPU time of the systemd processes 
was between a few seconds (for a machine that really does nothing 
useful), ~16 minutes (most normal machines), and one had 50 minutes (our 
most busy machine).


So as far as I'm concerned, this update can be released.

--
Mit freundlichen Grüßen,
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#587675: apcupsd: init script should report errors

[Martin von Wittich]

Package: apcupsd
Version: 3.14.8-2
Severity: normal

When starting apcupsd via init script the init script fails to report errors.
E.g. if you don't have a UPS connected to the computer apcupsd won't start, but
the init script will report a success condition nonetheless.

The behaviour is similar when starting apcupsd directly; it will immediately
fork and the original process will exit without an error message. The forked
process will try to connect to the UPS in the background; when this fails, it
will die silently after a few seconds. Only if I increase the debug level an
error message appears after a while, but due to the fork apcupsd still returns
with exit code 0 signalling success:

iserv ~ # apcupsd -d 100; echo $?
0.000 apcupsd: apcupsd.c:219 Options parsed.
0.004 apcupsd: apcupsd.c:242 Config file /etc/apcupsd/apcupsd.conf processed.
0.004 apcupsd: newups.c:102 write_lock at drivers.c:208
0.004 apcupsd: drivers.c:210 Looking for driver: usb
0.004 apcupsd: drivers.c:214 Driver dumb is configured.
0.004 apcupsd: drivers.c:214 Driver apcsmart is configured.
0.004 apcupsd: drivers.c:214 Driver net is configured.
0.004 apcupsd: drivers.c:214 Driver usb is configured.
0.004 apcupsd: drivers.c:217 Driver usb found and attached.
0.004 apcupsd: newups.c:108 write_unlock at drivers.c:234
0.004 apcupsd: drivers.c:236 Driver ptr=0x806c890
0.004 apcupsd: apcupsd.c:261 Attached to driver: usb
0.004 apcupsd: newups.c:102 write_lock at linux-usb.c:582
0
iserv ~ #
10.039 apcupsd: newups.c:108 write_unlock at linux-usb.c:601
apcupsd FATAL ERROR in linux-usb.c at line 609
Cannot find UPS device --
For a link to detailed USB trouble shooting information,
please see .
10.039 apcupsd: apclog.c:62 apcupsd FATAL ERROR in linux-usb.c at line 609
Cannot find UPS device --
For a link to detailed USB trouble shooting information,
please see .

10.039 apcupsd: newups.c:102 write_lock at linux-usb.c:631
10.039 apcupsd: newups.c:108 write_unlock at linux-usb.c:638
10.039 apcupsd: apclog.c:62 apcupsd error shutdown completed

I realize that apcupsd probably forks so the user doesn't have to wait, but in
this case I would prefer it to block until it has determined it can actually
connect, and only then return with exit code 0, and with a non-zero exit code
otherwise. This would be especially useful for scripting purposes.

-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apcupsd depends on:
ii  libc6   2.7-18lenny4 GNU C Library: Shared libraries
ii  libgcc1 1:4.3.2-1.1  GCC support library
ii  libwrap07.6.q-16 Wietse Venema's TCP wrappers libra

Versions of packages apcupsd recommends:
pn  apcupsd-doc(no description available)

Versions of packages apcupsd suggests:
pn  apcupsd-cgi(no description available)
pn  hal(no description available)
ii  udev  0.125-7+lenny3 /dev/ and hotplug management daemo

-- 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#588290: dhcp-eval: hardware operator does not work

[Martin von Wittich]

Package: dhcp3-server
Version: 3.1.1-6+lenny4
Severity: normal

I'm trying to write a script that puts all leases assigned by the DHCP server
into a database. My dhcpd config looks like this (minimal example):

---
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;

subnet 192.168.90.0 netmask 255.255.255.0 {
  range 192.168.90.200 192.168.90.210;

  on commit {
log(hardware);
set ip = binary-to-ascii(10, 8, ".", leased-address);
set mac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/root/Martin/dhcp", "commit", ip, "mac", mac);
  }
}
---

But when trying to start the DHCP server, I get the following error message:

dhcpd.conf.test line 12: Bogus number mac: digit 22 not in base 16
execute("/root/Martin.(nobackup)/dhcp", "commit", ip, "mac", mac)
 ^
Configuration file errors encountered -- exiting


When I now disable the last 3 commands in the on commit block, dhcpd works, but
apperantly the hardware operator does not return any useful info when it is
logged:

Jul  6 23:47:18 iserv dhcpd: #001

This does not fit the description from man dhcp-eval:

> The hardware operator returns a data string whose first element is the type
> of network interface indicated  in  packet  being  considered,  and whose
> subsequent elements are client’s link-layer address.

-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dhcp3-server depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii  debianutils   2.30   Miscellaneous utilities specific t
ii  dhcp3-common  3.1.1-6+lenny4 common files used by all the dhcp3
ii  libc6 2.7-18lenny4   GNU C Library: Shared libraries
ii  lsb-base  3.2-20 Linux Standard Base 3.2 init scrip

dhcp3-server recommends no packages.

Versions of packages dhcp3-server suggests:
pn  dhcp3-server-ldap  (no description available)

-- debconf information:
* dhcp3-server/new_auth_behavior:
* dhcp3-server/interfaces: eth0
  dhcp3-server/new_next-server_behaviour:
  dhcp3-server/config_warn:



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

Bug#585146: lspci: query the database for specific vendor/device IDs

[Martin von Wittich]

Package: pciutils
Version: 1:3.0.0-6
Severity: wishlist

When dealing with computers that don't have lspci (e.g. Windows), it's usually
possible to determine the vendor and device ID of an unknown device. It would
be nice if lspci could be used to query the PCI database with these IDs to
determine the device's name.

Example: If I have a computer that has an unknown device 1217:7130, lspci
should tell me what this device is (the --query parameter is hypothetical):

lspci --query 1217:7130
O2 Micro, Inc. Integrated MS/xD Controller

lspci has a -d switch that "show[s] only devices with specified vendor and
device ID", but that only limits the selection of local devices to the
specified IDs. It does not currently seem to be possible to query the database
for arbitrary IDs when the devices are not installed in the local computer.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages pciutils depends on:
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries
ii  libpci3 1:3.0.0-6Linux PCI Utilities (shared librar

pciutils recommends no packages.

Versions of packages pciutils suggests:
ii  bzip21.0.5-1 high-quality block-sorting file co
ii  curl 7.18.2-8lenny4  Get a file from an HTTP, HTTPS or 
ii  lynx 2.8.7dev9-2.1   Text-mode WWW Browser (transitiona
ii  wget 1.11.4-2+lenny1 retrieves files from the web

-- 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#617254: debtags parses obsolete *_Packages files from /var/lib/apt/lists

[Martin von Wittich]

Package: debtags
Version: 1.7.8.1
Severity: normal

'debtags update' (or rather the /usr/share/debtags/fetch script) simply parses
all /var/lib/apt/lists/*_Packages files without considering that some of these
files may be no longer in use and contain obsolete information. This causes
problems with our software that relies on debtags; it expects
/var/lib/debtags/package-tags to contain only packages that are actually
available in the repository, but due to this bug this file also contains
packages that are mentioned in old lists but that are no longer available.

The problem is aggravated by aptitude bug #507603 on lenny which causes old
lists to pile up in /var/lib/apt/lists.

-- System Information:
Debian Release: 5.0.8
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages debtags depends on:
ii  apt [libapt-pkg-libc6. 0.7.20.2+lenny2   Advanced front-end for dpkg
ii  libc6  2.7-18lenny7  GNU C Library: Shared libraries
ii  libept00.5.22High-level library for managing De
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  libxapian151.0.7-4   Search engine library
ii  perl   5.10.0-19lenny3   Larry Wall's Practical Extraction 
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

debtags recommends no packages.

Versions of packages debtags suggests:
pn  tagcoll(no description available)
ii  wget 1.11.4-2+lenny2 retrieves files from the web

-- 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#583836: file should report the encoding for e.g. source code files

[Martin von Wittich]

Package: file
Version: 4.26-1
Severity: wishlist

file can detect the encoding of plain text files:

$ file iso8859.txt
iso8859.txt: ISO-8859 text

However, it won't do this for e.g. Perl scripts:

$ file iso8859.pl
iso8859.pl:  a /usr/bin/perl script text executable

This is IMO an inconsistent behaviour. I was always wondering why file detected
the encoding reliably in some cases and not at all in others until I noticed
that it only works for text files. With a trick it's possible to detect the
encoding anyway:

$ file -m /dev/null iso8859.pl
iso8859.pl: ISO-8859 text

but this is not intuitive. I found it by looking through the manpage and trying
every option :)

file should either print the encoding of non-text files by default or it should
have a switch to enable that behaviour.


-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages file depends on:
ii  libc6  2.7-18lenny2  GNU C Library: Shared libraries
ii  libmagic1  4.26-1File type determination library us
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

file recommends no packages.

file 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#622254: shutdown: should log warning message to syslog

[Martin von Wittich]

Package: sysvinit
Version: 2.86.ds1-61
Severity: wishlist

shutdown(8) can display a warning message via wall(1) before the computer is
shut down. acpid(8) uses this to display the warning message "Power button
pressed" (configured in /etc/acpi/powerbtn.sh), but this information is never
logged and thus lost. I could hack a logger(1) call into my powerbtn.sh to
circumvent this, but I think it would be nicer if shutdown(8) would generally
log the warning message to syslog before it shuts the computer down.

-- System Information:
Debian Release: 5.0.8
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sysvinit depends on:
ii  initscripts 2.86.ds1-61  Scripts for initializing and shutt
ii  libc6   2.7-18lenny7 GNU C Library: Shared libraries
ii  libselinux1 2.0.65-5 SELinux shared libraries
ii  libsepol1   2.0.30-2 Security Enhanced Linux policy lib
ii  sysv-rc 2.86.ds1-61  System-V-like runlevel change mech
ii  sysvinit-utils  2.86.ds1-61  System-V-like utilities

sysvinit recommends no packages.

sysvinit 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#900510: squidguard: SIGHUP crashes squidGuard instead of reloading it

[Martin von Wittich]

Package: squidguard
Version: 1.5-4
Severity: normal
Tags: upstream

Dear Maintainer,

squidGuard seems to support the SIGHUP signal to reload its
configuration, as is common for daemons. Though this doesn't seem to be
documented as far as I can tell, from the code it's obvious that it
should be supported - main.c at several points checks for sig_hup and calls
sgReloadConfig, for example:

  if(sig_hup) {
sgReloadConfig();
  }

sgReloadConfig is defined like this:

  void sgReloadConfig()
  {
struct LogFileStat *sg;
struct Source *src;
struct Destination *dest;
sig_hup = 0;
sgLogWarn("WARN: Received sigHUP, reloaded configuration");
for(sg = LogFileStat; sg != NULL; sg = sg->next){ /* closing logfiles */
  if(sg->fd == stderr || sg->fd == stdout) {
continue;
  }
  fclose(sg->fd);
}
for(src = Source; src != NULL; src = src->next){
  if(src->domainDb != NULL && src->domainDb->dbp != NULL) {
(void)src->domainDb->dbp->close(src->domainDb->dbp,0);
  }
  if(src->userDb != NULL && src->userDb->dbp != NULL) {
(void)src->userDb->dbp->close(src->userDb->dbp,0);
  }
}
for(dest = Dest; dest != NULL; dest = dest->next){
  if(dest->domainlistDb != NULL && dest->domainlistDb->dbp != NULL) {
(void)dest->domainlistDb->dbp->close(dest->domainlistDb->dbp,0);
  }
  if(dest->urllistDb != NULL && dest->urllistDb->dbp != NULL) {
(void)dest->urllistDb->dbp->close(dest->urllistDb->dbp,0);
  }
}
sgFreeAllLists();
execve(*globalArgv,globalArgv, globalEnvp);
fprintf(stderr,"error execve: %d\n",errno);
exit(1);
  }

Unfortunately, this doesn't work as expected when squidGuard is used as
url_rewrite_program in squid - sending SIGHUP to squidGuard will crash
it instead of reloading it. To reproduce:

1. strace squidGuard (works best when only a single instance is
   running):

strace -p $(pidof '(squidGuard)')

2. Send SIGHUP:

pkill -SIGHUP squidGuard

3. Observe in strace that squidGuard has received the SIGHUP, but
   nothing bad has happened yet:

host ~ # strace -p $(pidof '(squidGuard)')
Process 5598 attached
read(0, 0xf7779000, 4096)   = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=8385, si_uid=0} ---
sigreturn() (mask [])   = 3
read(0,

4. Send a request to squid:

http_proxy=http://localhost:3128 GET google.de > /dev/null

5. Observe in strace that squidGuard crashes:

host ~ # strace -p $(pidof '(squidGuard)')
Process 8452 attached
read(0, 0xf7737000, 4096)   = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=8503, si_uid=0} ---
sigreturn() (mask [])   = 3
read(0, "http://google.de/ 127.0.0.1/loca"..., 4096) = 71
time(NULL)  = 1527782365
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(5, "2018-05-31 17:59:25 [8452] WARN:"..., 73) = 73
close(4)= 0
munmap(0xf7745000, 4096)= 0
close(6)= 0
munmap(0xf7743000, 4096)= 0
close(11)   = 0
munmap(0xf7742000, 4096)= 0
close(14)   = 0
munmap(0xf7741000, 4096)= 0
close(17)   = 0
munmap(0xf774, 4096)= 0
close(20)   = 0
munmap(0xf773f000, 4096)= 0
close(23)   = 0
munmap(0xf773e000, 4096)= 0
close(26)   = 0
munmap(0xf773d000, 4096)= 0
close(29)   = 0
munmap(0xf773c000, 4096)= 0
close(32)   = 0
munmap(0xf773b000, 4096)= 0
close(35)   = 0
munmap(0xf773a000, 4096)= 0
close(38)   = 0
munmap(0xf7739000, 4096)= 0
close(41)   = 0
munmap(0xf7738000, 4096)= 0
close(5)= 0
munmap(0xf7744000, 4096)= 0
close(7)= 0
close(8)= 0
close(9)= 0
close(10)   = 0
close(12)   = 0
close(13)   = 0
close(15)   = 0
close(16)   = 0
close(18)   = 0
close(19)   = 0
close(21)   = 0
close(22

Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

[Martin von Wittich]

We're having the same problem here. For some reason, only 2 domUs are 
affected (the dom0 has a total of 22 domUs, 14 of those are running 
Debian stretch, and 13 of those are running Linux 4.9.51-1).


The `xl console` output of the first domU (according to our monitoring 
it hangs since yesterday 14:06):



[ 3746.780086] INFO: task ntpd:670 blocked for more than 120 seconds.
[ 3746.780094]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3746.780097] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3746.780223] INFO: task jbd2/xvdb6-8:8173 blocked for more than 120 seconds.
[ 3746.780228]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3746.780233] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3746.780304] INFO: task rsync:8188 blocked for more than 120 seconds.
[ 3746.780308]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3746.780311] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612083] INFO: task jbd2/xvda1-8:203 blocked for more than 120 seconds.
[ 3867.612091]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612091] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612148] INFO: task ntpd:670 blocked for more than 120 seconds.
[ 3867.612150]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612152] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612238] INFO: task jbd2/xvdb6-8:8173 blocked for more than 120 seconds.
[ 3867.612242]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3867.612287] INFO: task rsync:8188 blocked for more than 120 seconds.
[ 3867.612291]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3867.612294] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3988.444071] INFO: task jbd2/xvda1-8:203 blocked for more than 120 seconds.
[ 3988.444080]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3988.444084] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3988.444154] INFO: task ntpd:670 blocked for more than 120 seconds.
[ 3988.444159]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3988.444162] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 3988.444266] INFO: task kworker/2:0:1533 blocked for more than 120 seconds.
[ 3988.444271]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[ 3988.444274] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.


The other domU had a similar error message before a coworker downgraded 
the kernel to 3.16 get it working again:



INFO: task jbd2/xvda1-8:191 blocked for more than 120 seconds.
[  605.148107]   Not tainted 4.9.0-4-amd64 #1 Debian 4.9.51-1
[  605.148111] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.


The first domU is a backup machine, it mainly uses rsync --link-dest to 
pull backups from other machines, and is therefore rather IO intensive. 
The other domU is a firewall/router and shouldn't be IO intensive at all.


--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#878768: systemd: *.dpkg-remove.service entries in systemctl

[Martin von Wittich]

Am 16.10.2017 um 17:52 schrieb Michael Biebl:

systemd should already ignore files ending in dpkg-remove, see
https://github.com/systemd/systemd/blob/master/src/basic/path-util.c#L808

Not surprisingly, I was not able to reproduce your problem.

Can you provide steps how I can reproduce the problem (ideally starting
with pristine stretch installation)


Hmm, the affected server was only upgraded to stretch on 2017-10-14. 
Maybe it was the old systemd (215-17+deb8u7 according to the dpkg.log) 
that added these services during the upgrade to stretch, and the systemd 
in stretch would no longer do that?


Apparently ignoring *.dpkg-remove files was added with 
c7088e4999f2e5dd33259948c806f4e2706e77ce on 2015-01-21:


https://github.com/systemd/systemd/commit/c7088e4999f2e5dd33259948c806f4e2706e77ce

If I'm reading that correctly, that commit was only included with v219, 
so it seems likely that jessie's systemd was affected, but the version 
in stretch isn't. I'd say this bug report can be closed then. Thanks for 
taking the time trying to reproduce this issue, and sorry for wasting 
your time.


For others stumbling over this issue: I was able to get rid of the 
broken services by running "systemctl stop service, e.g. "systemctl stop hdparm.dpkg-remove.service".


--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Jörg Ludwig

Bug#926576: This also affects stretch (cups-filters 1.11.6-3)

[Martin von Wittich]

Hi,

this also affects stretch:


server ~ # apt-cache policy cups-filters
cups-filters:
  Installiert:   1.11.6-3
  Installationskandidat: 1.11.6-3
  Versionstabelle:
 *** 1.11.6-3 500
500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status


Today a ghostscript update was released that broke printing for us:


server ~ # grep upgrade /var/log/dpkg.log | tail -n3
2019-05-13 02:58:10 upgrade ghostscript:amd64 9.26a~dfsg-0+deb9u2 
9.26a~dfsg-0+deb9u3
2019-05-13 02:58:11 upgrade libgs9:amd64 9.26a~dfsg-0+deb9u2 9.26a~dfsg-0+deb9u3
2019-05-13 02:58:12 upgrade libgs9-common:all 9.26a~dfsg-0+deb9u2 
9.26a~dfsg-0+deb9u3



server ~ # zcat /usr/share/doc/ghostscript/changelog.Debian.gz | head -n8
ghostscript (9.26a~dfsg-0+deb9u3) stretch-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * Hide pdfdict and GS_PDF_ProcSet (internal stuff for the PDF interp)
(CVE-2019-3839)
  * Fix lib/pdf2dsc.ps to use documented Ghostscript pdf procedures

 -- Salvatore Bonaccorso   Fri, 10 May 2019 15:21:33 +0200


server ~ # tail /var/log/cups/error_log 
D [13/May/2019:11:24:14 +0200] [Job 8519] Process is dying with \"Unable to determine number of pages, page count: -1

D [13/May/2019:11:24:14 +0200] [Job 8519] \", exit stat 3
D [13/May/2019:11:24:14 +0200] [Job 8519] Cleaning up...
D [13/May/2019:11:24:14 +0200] [Job 8519] PID 20636 
(/usr/lib/cups/filter/foomatic-rip) stopped with status 3.
D [13/May/2019:11:24:14 +0200] [Job 8519] Hint: Try setting the LogLevel to 
"debug" to find out more.
D [13/May/2019:11:24:14 +0200] [Job 8519] PID 20637 
(/usr/lib/cups/backend/socket) exited with no errors.
D [13/May/2019:11:24:14 +0200] [Job 8519] End of messages
D [13/May/2019:11:24:14 +0200] [Job 8519] printer-state=3(idle)
D [13/May/2019:11:24:14 +0200] [Job 8519] printer-state-message="Filter failed"
D [13/May/2019:11:24:14 +0200] [Job 8519] 
printer-state-reasons=toner-empty-warning


Can we get a backport for stretch too?

--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig

Bug#926896: sysvinit-utils: pidof is unreliable

[Martin von Wittich]

I also just noticed this issue. We have a piece of code in our software 
that uses pidof to wait to apcupsd to start; I've reduced it to the 
following minimal working example:



#!/bin/bash

set -eu

systemctl restart apcupsd

#sleep 1

echo "Connecting to ups, please wait..."
START=$SECONDS

while pidof -s apcupsd >/dev/null
do
  if RES="$(apcaccess)"
  then
if grep -q "^STATUS *: *COMMLOST" <<< "$RES"
then
  break
elif grep -q "^STATUS *: *ONLINE" <<< "$RES"
then
  MODEL="$(sed -n 's/^MODEL *: *//p' <<< "$RES")"
  echo -e "Connection established:\n$MODEL"
  exit 0
fi
  fi
  if [ $((SECONDS - START)) -ge 30 ]
  then
break
  fi
  sleep 1
  echo -n .
done

echo "Connection failed!"


This worked fine for years, for example on a stretch server:

stretch-server ~ # ./test.sh
Connecting to ups, please wait...
Connection established:
Smart-UPS 750

But it doesn't work on a buster server:

buster-server ~ # ./test.sh
Connecting to ups, please wait...
Connection failed!

apcupsd is running, but for some reason, pidof isn't able to see it yet 
and therefore returns 1, which immediately terminates the loop. If you 
uncomment the sleep 1, it'll work:


buster-server ~ # ./test.sh
Connecting to ups, please wait...
Connection established:
Smart-UPS 750

Apparently the issue occurs only for very new processes...? The 
following script shows how pidof isn't able to see the process when it 
should be able to:



#!/bin/bash

set -eu
systemctl restart apcupsd
START=$SECONDS

ps aux|grep apcupsd
while true
do
  echo -n "pidof: "
  pidof -s apcupsd || echo
  [ $((SECONDS - START)) -ge 2 ] && break
  sleep 0.01
done
ps aux|grep apcupsd


Output on stretch, where pidof works fine:


stretch-server ~ # ./pidof.sh
root  6251  0.0  0.0  20420   180 ?Ssl  14:57   0:00 
/sbin/apcupsd
root  6255  0.0  0.0   5128   800 pts/2S+   14:57   0:00 grep 
apcupsd

pidof: 6251
[removed all duplicate lines...]
pidof: 6251
root  6251  0.0  0.0  20420   180 ?Ssl  14:57   0:00 
/sbin/apcupsd
root  6380  0.0  0.0   5128   852 pts/2S+   14:57   0:00 grep 
apcupsd


Output on buster:


buster-server ~ # ./pidof.sh
root 26609  0.0  0.0  87144  2060 ?Dsl  15:00   0:00 
/sbin/apcupsd
root 26613  0.0  0.0   6424   884 pts/8S+   15:00   0:00 grep 
apcupsd

pidof:
pidof:
pidof:
pidof:
pidof:
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof:
pidof: 26609
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
root 26609  0.0  0.0  87144  2060 ?Ssl  15:00   0:00 
/sbin/apcupsd
root 26739  0.0  0.0   6424   884 pts/8S+   15:00   0:00 grep 
apcupsd



There's always at least 4-6 empty "pidof:" lines at the beginning, so 
apparently pidof never works in the ~40-60ms after a process was 
launched. But there are almost always holes in the output further on, so 
it's also slightly unreliable afterwards.


--
Mit freundlichen Grüßen
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon: 0531-2243666-0
Fax: 0531-2243666-9
E-Mail: i...@iserv.eu
Internet: iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy

Bug#926896: sysvinit-utils: pidof is unreliable

[Martin von Wittich]

Am 20.10.19 um 20:59 schrieb Dmitry Bogatov:


That sounds explainable. pidof() scans /proc directory, and it takes some
time for kernel to create entry there.


Hm, is there really a delay? I'm not very deep into kernel development, 
but as far as I understand /proc, it isn't populated by the kernel after 
a process has been created, but instead represents direct access to 
internal kernel data structures. So as far as I know, there shouldn't be 
any delay after a process has been created before it's accessible via 
/proc/.


Even if there were, that wouldn't explain how ps is able to see the 
process, while pidof is not. As far as I know, ps also gets this 
information from /proc.


To verify my assumptions, I've adapted my test script as follows:

#!/bin/bash

set -eu
systemctl restart apcupsd
START=$SECONDS

ps -f -C apcupsd
PID="$(ps -o pid -C apcupsd --noheaders)"
ls /proc/"$PID"

while true
do
  echo -n "pidof: "
  pidof -s apcupsd || echo
  echo -n "ls: "
  ls -d /proc/"$PID"
  [ $((SECONDS - START)) -ge 2 ] && break
  sleep 0.01
done
ps -f -C apcupsd


The output:

buster-server ~ # ./pidof.sh
UIDPID  PPID  C STIME TTY  TIME CMD
root 26476 1  0 14:16 ?00:00:00 /sbin/apcupsd
attr   clear_refs   cpuset   fd   limits mem net 
   oom_score  personality  schedstat  smaps_rollup  status 
timerslack_ns
autogroup  cmdline  cwd  fdinfo   loginuid   mountinfo   ns 
   oom_score_adj  projid_map   sessionid  stack syscall 
uid_map
auxv   comm environ  gid_map  map_files  mounts 
numa_maps  pagemaproot setgroups  stat  task 
wchan
cgroup coredump_filter  exe  io   maps   mountstats 
oom_adjpatch_stateschedsmaps  statm timers 


pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof:
ls: /proc/26476
pidof: 26476
ls: /proc/26476
pidof: 26476

So the /proc/26476 is there even when pidof doesn't see the process.


But there are almost always holes in the output further on, so it's
also slightly unreliable afterwards.


This is really wierd, given that pid is same: process is not restarted.


#!/bin/bash

set -eu

systemctl restart apcupsd


Do you have receipe to reproduce issue on systemd-free box, so I can try
to debug issue myself?


Unfortunately no, I only have access to machines with systemd :(
Does replacing "systemctl restart apcupsd" with "/etc/init.d/apcupsd" work?

I had assumed that the problem should be easily reproducible with any 
other recently-started process, but that is apparently not the case:


buster-server ~ # cat sleep.sh
#!/bin/bash

set -eu
sleep 2 &
START=$SECONDS

ps aux|grep sleep
while true
do
  echo -n "pidof: "
  pidof -s sleep || echo
  [ $((SECONDS - START)) -ge 2 ] && break
  sleep 0.01
done
ps aux|grep sleep

Output:

buster-server ~ # ./sleep.sh
root 26946  0.0  0.0   6980  3120 pts/3S+   14:19   0:00 
/bin/bash ./sleep.sh

root 26947  0.0  0.0   5596   752 pts/3S+   14:19   0:00 sleep 2
root 26949  0.0  0.0   6424   884 pts/3S+   14:19   0:00 grep sleep
pidof: 26947
pidof: 26947
pidof: 26947
pidof: 26947
pidof: 26947
[no holes like with apcupsd...]
pidof: 26947
pidof: 26947
root 26946  1.5  0.0   7112  3376 pts/3S+   14:19   0:00 
/bin/bash ./sleep.sh

root 26947  0.0  0.0   5596   752 pts/3S+   14:19   0:00 sleep 2
root     27069  0.0  0.0   6424   884 pts/3S+   14:19   0:00 grep sleep

Maybe systemd is somehow involved?

--
Mit freundlichen Grüßen
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon: 0531-2243666-0
Fax: 0531-2243666-9
E-Mail: i...@iserv.eu
Internet: iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy

Bug#943387: upgrade-from-grub-legacy: environment variable DPKG_MAINTSCRIPT_NAME is required

[Martin von Wittich]

Package: grub-pc
Version: 2.02~beta3-5+deb9u2
Severity: normal
Tags: patch

Dear Maintainer,

apparently, one of our servers still has some GRUB legacy files
installed, which causes `dpkg-reconfigure grub-pc` to tell me that I
have to run `upgrade-from-grub-legacy`. That doesn't work though:


host ~ # upgrade-from-grub-legacy

core.img doesn't exist, trying to create it.

i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
done
dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is 
required


I've looked into the script and determined that the following command causes
this error:


host ~ # UPGRADE_FROM_GRUB_LEGACY=1 /var/lib/dpkg/info/grub-pc.postinst 
configure dummy-version
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
dpkg: Warnung: Version »dummy-version« hat falsche Syntax: Versionsnummer 
beginnt nicht mit einer Ziffer
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-8-amd64
Found initrd image: /boot/initrd.img-4.9.0-8-amd64
done
dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is 
required


As far as I can tell, the issue occurs because upgrade-from-grub-legacy calls
the postinst directly without providing the DPKG_MAINTSCRIPT_NAME environment
variable (which dpkg would do when it calls a maintainer script), and the
command dpkg-maintscript-helper inside this postinst script then fails because
it requires this variable.

I've attached a patch that resolves the issue for me.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/md1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/2f9ea6c5164b0a0923d88379717a4435cb4250e0d8fe8b707f32eae1e70a212d/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/577647308b1ba37730d8006f453628b5042427485e0927957171872b10d6c37a/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/10800baf61f8ba8b1d6c2fa68e023887f651c04d1996c21e7ba1947bbaf401d3/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/md1 
/var/lib/docker/containers/0525084a5e3e5504f7468fadf9bfb2f22ad7e5ee758e7b4270ffaa3d65d3/mounts
 ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X4QRBZ
(hd1)   /dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X4QRP9
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Martin von Wittich]

Package: systemd
Version: 232-25+deb9u1
Severity: normal
Tags: upstream

Dear Maintainer,

the following commands unexpectedly do not print any error messages or
return non-zero exit codes:

martin.mein-iserv.de ~ # systemctl stop postgresql@does-not-exist
martin.mein-iserv.de ~ # systemctl start postgresql@does-not-exist
martin.mein-iserv.de ~ # systemctl restart postgresql@does-not-exist

reload on the other hand does:

martin.mein-iserv.de ~ # systemctl reload postgresql@does-not-exist; echo $?
postgresql@does-not-exist.service is not active, cannot reload.
1

martin.mein-iserv.de ~ # systemctl stop does-not-exist
Failed to stop does-not-exist.service: Unit does-not-exist.service not loaded.
martin.mein-iserv.de ~ # systemctl restart does-not-exist
Failed to restart does-not-exist.service: Unit does-not-exist.service not found.
martin.mein-iserv.de ~ # systemctl restart does-not-exist
Failed to restart does-not-exist.service: Unit does-not-exist.service not found.
martin.mein-iserv.de ~ # systemctl reload does-not-exist
Failed to reload does-not-exist.service: Unit does-not-exist.service not found.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u2
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u1
ii  mount   2.29.2-1
ii  procps  2:3.3.12-3
ii  util-linux  2.29.2-1

Versions of packages systemd recommends:
ii  dbus1.10.24-0+deb9u1
ii  libpam-systemd  232-25+deb9u1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u1

-- no debconf information

Bug#891836: systemd: systemctl start/stop/restart valid-template@invalid-instance doesn't cause errors

[Martin von Wittich]

Hi Michael,

On Thu, 1 Mar 2018 15:10:26 +0100 Michael Biebl  wrote:

I can't reproduce this, neither on v237 nor on v232:

# systemctl stop postgresql@does-not-exist
Failed to stop postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not loaded.

# systemctl start postgresql@does-not-exist
Failed to start postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.

# systemctl restart postgresql@does-not-exist
Failed to restart postgresql@does-not-exist.service: Unit
postgresql@does-not-exist.service not found.


Do you have a postgresql template installed (should be the case when you 
have a postgresql-9.{4,6} (jessie/stretch) server package installed)? If 
not, try another template, maybe getty (I hope that's available on every 
system, would make reproducing this a lot easier):


stable.iserv.eu ~ # systemctl stop getty@does-not-exist
stable.iserv.eu ~ #

If the template itself doesn't exist, this leads to the expected error 
message:


stable.iserv.eu ~ # systemctl stop does-not-exist@does-not-exist
Failed to stop does-not-exist@does-not-exist.service: Unit 
does-not-exist@does-not-exist.service not loaded.


To ensure that this issue is not caused by our custom server 
configuration, I also tried to reproduce the issue on my Ubuntu 17.10 
client:


martin@dogmeat ~ % systemd --version
systemd 234
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS 
+KMOD -IDN2 +IDN default-hierarchy=hybrid


martin@dogmeat ~ % sudo systemctl restart getty@does-not-exist
martin@dogmeat ~ %

--
Mit freundlichen Grüßen
Martin v. Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:   0531-2243666-9
E-Mail:i...@iserv.eu
Internet:  iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig

Bug#892173: e2fsprogs: Bug in German l10n of "Inode 529618 extent tree (at level 1) could be shorter"

[Martin von Wittich]

Package: e2fsprogs
Version: 1.43.4-2
Severity: minor
Tags: l10n

Dear Maintainer,

the German localization of the following message:

some-server ~ # LANG=C e2fsck -f /dev/vg/some-lv
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Inode 529618 extent tree (at level 1) could be shorter.  Fix?

contains uninterpreted escape sequences instead of the actual values:

some-server ~ # LANG=de_DE.UTF-8 e2fsck -f /dev/vg/some-lv
e2fsck 1.43.4 (31-Jan-2017)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Der Erweiterungsbaum von Inode %$i (auf Ebene %$b) könnte kürzer sein.  
Reparieren?

If I understand the issue correctly, the translations are attempting to use a
printf escape that might not be supported by the compiler...? Wikipedia says
"Parameter field - This is a POSIX extension and not in C99."

The following *.po files might be affected:

martin@dogmeat ~/Projects/e2fsprogs/po % grep -lP '\d\$' *.po
cs.po
de.po
hu.po
nl.po
pl.po
tr.po
vi.po
zh_CN.po

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

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

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.43.4-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcomerr2  1.43.4-2
ii  libss2  1.43.4-2
ii  libuuid12.29.2-1
ii  util-linux  2.29.2-1

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
pn  parted 

-- no debconf information

Bug#1093696: rsync: segfault in write_sparse since rsync 3.2.3-4+deb11u2

[Martin von Wittich]

Package: rsync
Version: 3.2.3-4+deb11u3
Severity: normal
X-Debbugs-Cc: debian-...@lists.debian.org

Dear Maintainer,

since the recent security updates to rsync, we're seeing segfaults on
several of our customer's backup servers which are mostly running on
Debian bullseye. The affected versions so far seem to be 3.2.3-4+deb11u2
(the first version that caused segfaults on Debian bullseye servers),
3.2.3-4+deb11u3 (still causing segfaults), and 3.2.7-1+deb12u2 (still
causing segfaults after we upgraded one of the affected servers to Debian
bookworm):

5bdb2681 ~ # zgrep segf /var/log/syslog*(.Om)
/var/log/syslog-20250120:Jan 20 21:07:01 backup kernel: [6120345.736990] 
rsync[1616623]: segfault at 0 ip 55918f690fb0 sp 7cfa0950 error 4 
in rsync[55918f653000+52000]

5bdb2681 ~ # grep rsync /var/log/dpkg.log(.Om) | grep upgrade
2025-01-15 03:06:35 upgrade rsync:amd64 3.2.3-4+deb11u1 3.2.3-4+deb11u2
2025-01-18 03:06:36 upgrade rsync:amd64 3.2.3-4+deb11u2 3.2.3-4+deb11u3
2025-01-21 12:02:56 upgrade rsync:amd64 3.2.3-4+deb11u3 3.2.7-1+deb12u2

5bdb2681 ~ # gdb x/usr/bin/rsync /var/tmp/core_rsync_1737403621_1616623 -ex bt
[...]
Core was generated by `rsync -e ssh -o LogLevel=ERROR -o BatchMode=yes --delete 
--stats --no-human-rea'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55918f690fb0 in write_sparse (len=1024, buf=0x0, offset=0, 
use_seek=1, f=3) at fileio.c:79
79  fileio.c: Datei oder Verzeichnis nicht gefunden.
#0  0x55918f690fb0 in write_sparse (len=1024, buf=0x0, offset=0, 
use_seek=1, f=3) at fileio.c:79
#1  write_file (f=f@entry=3, use_seek=use_seek@entry=1, offset=offset@entry=0, 
buf=buf@entry=0x0, len=len@entry=4368) at fileio.c:153
#2  0x55918f6912db in skip_matched (fd=fd@entry=3, offset=offset@entry=0, 
buf=buf@entry=0x0, len=len@entry=4368) at fileio.c:193
#3  0x55918f667bea in receive_data (f_in=f_in@entry=5, 
fname_r=fname_r@entry=0x55918f6d2400  
"/var/lib/iserv/backup/mnt/sda4/iserv/.rsync-partial/access.log", 
fd_r=fd_r@entry=-1, size_r=, 
fname=fname@entry=0x7cfa0be0 "var/log/nginx/access.log", fd=fd@entry=3, 
file=0x5591affa15b8, inplace_sizing=1) at receiver.c:361
#4  0x55918f668e61 in recv_files (f_in=f_in@entry=5, f_out=f_out@entry=6, 
local_name=local_name@entry=0x0) at receiver.c:875
#5  0x55918f673f81 in do_recv (f_in=f_in@entry=5, f_out=6, f_out@entry=4, 
local_name=local_name@entry=0x0) at main.c:1052
#6  0x55918f674b20 in client_run (f_in=5, f_out=4, pid=pid@entry=1616622, 
argc=argc@entry=1, argv=argv@entry=0x5591aaa965d8) at main.c:1365
#7  0x55918f65462a in start_client (argv=, argc=1) at 
main.c:1583
#8  main (argc=, argv=) at main.c:1815


4fa1ef0d ~ # zgrep segf /var/log/syslog*(.Om)
/var/log/syslog-20250115.gz:Jan 15 21:31:09 backup kernel: [4480322.015591] 
rsync[2032758]: segfault at 0 ip 560bd2860f60 sp 7ffee3cca280 error 4 
in rsync[560bd2823000+52000]
/var/log/syslog-20250116.gz:Jan 16 21:28:45 backup kernel: [4566579.181588] 
rsync[2066066]: segfault at 0 ip 55f08ef02f60 sp 7ffdb3df4550 error 4 
in rsync[55f08eec5000+52000]
/var/log/syslog-20250117.gz:Jan 17 21:30:09 backup kernel: [4653065.047654] 
rsync[2098363]: segfault at 0 ip 55d9e9f3df60 sp 7ffe4cbc7be0 error 4 
in rsync[55d9e9f0+52000]
/var/log/syslog-20250118.gz:Jan 18 21:25:53 backup kernel: [4739210.812916] 
rsync[2132252]: segfault at 0 ip 55ad89374fb0 sp 7ffc3c938460 error 4 
in rsync[55ad89337000+52000]
/var/log/syslog-20250119.gz:Jan 19 21:27:52 backup kernel: [4825731.020182] 
rsync[2162792]: segfault at 0 ip 562472ccefb0 sp 7ffdfc153ea0 error 4 
in rsync[562472c91000+52000]
/var/log/syslog-20250120:Jan 20 21:28:57 backup kernel: [4912198.286147] 
rsync[2199490]: segfault at 0 ip 55cfd1aeefb0 sp 7ffc819c79a0 error 4 
in rsync[55cfd1ab1000+52000]
/var/log/syslog:Jan 21 08:54:39 backup kernel: [4953340.644919] rsync[2226848]: 
segfault at 0 ip 5609330c6fb0 sp 7ffea8927420 error 4 in 
rsync[560933089000+52000]
/var/log/syslog:Jan 21 09:26:52 backup kernel: [4955273.333927] rsync[2242720]: 
segfault at 0 ip 56117dcf7fb0 sp 7ffde2f5b4c0 error 4 in 
rsync[56117dcba000+52000]
/var/log/syslog:Jan 21 13:24:07 backup kernel: [ 2881.529493] rsync[3403]: 
segfault at 0 ip 55b95f896c38 sp 7ffd9c34eeb0 error 4 in 
rsync[55b95f856000+56000] likely on CPU 0 (core 0, socket 0)
/var/log/syslog:Jan 21 14:10:08 backup kernel: [ 5642.034167] rsync[18926]: 
segfault at 0 ip 5652ecc17c38 sp 7fff0f09d150 error 4 in 
rsync[5652ecbd7000+56000] likely on CPU 0 (core 0, socket 0)
/var/log/syslog:Jan 21 14:38:11 backup kernel: [ 7325.145931] rsync[40067]: 
segfault at 0 ip 55975f5e6c38 sp 7ffc69968160 error 4 in 
rsync[55975f5a6000+56000] likely on CPU 0 (core 0, socket 0)

4fa1ef0d ~ # grep rsync /var/log/dpkg.log(.Om) | grep upgrade
2025-01-15 03:38:23 upgrade rsync:amd64 3.2.3-4+deb11u1 3.2.3-4+deb11u2
2025-01-18 03:38:21 upgrade rsync:amd64 3.2.3-4+deb11u2 3.2.3