Bug#712999: Here too
Same issue here, but not always. CPU: model name : Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz Controller: 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06) Kernel 3.14-0.bpo.1-amd64 Stock wheezy kernel untested as its C600 driver is bugged so it really doesn't find any drives/lvs to mount. -- Tom Laermans IT Infrastructure Manager Luciad NV - http://www.luciad.com Gaston Geenslaan 11, 3001 Heverlee, Belgium -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743182: mediawiki: Mediawiki broken after security update
Package: mediawiki Version: 1:1.19.14+dfsg-0+deb7u1 Severity: grave Justification: renders package unusable Dear Maintainer, Updating from 1:1.19.5-1+deb7u1 to 1:1.19.14+dfsg-0+deb7u1 on Debian Wheezy, leads to the following errors in the apache log: [Mon Mar 31 11:12:45 2014] [error] [client 192.168.1.1] PHP Warning: require(/var/lib/mediawiki/includes/libs/HttpStatus.php): failed to open stream: No such file or directory in /usr/share/mediawiki/includes/AutoLoader.php on line 1009 [Mon Mar 31 11:12:45 2014] [error] [client 192.168.1.1] PHP Fatal error: require(): Failed opening required '/var/lib/mediawiki/includes/libs/HttpStatus.php' (include_path='/var/lib/mediawiki:/var/lib/mediawiki/includes:/var/lib/mediawiki/languages:/var/lib/mediawiki:/var/lib/mediawiki/includes:/var/lib/mediawiki/languages:.:/usr/share/php:/usr/share/pear') in /usr/share/mediawiki/includes/AutoLoader.php on line 1009 Confirm: root@puppet-test:~# dpkg -L mediawiki|grep HttpStatus root@puppet-test:~# Contrary to what https://packages.debian.org/wheezy/all/mediawiki/filelist is listing. Previous package: root@pluto:~# dpkg -L mediawiki|grep HttpStatus /usr/share/mediawiki/includes/libs/HttpStatus.php Reverting to 1:1.19.5-1+deb7u1 fixes this issue. I'm using the LDAP auth package as well but at first sight this doesn't matter. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 mediawiki depends on: ii apache2 2.2.22-13+deb7u1 ii apache2-mpm-prefork [httpd] 2.2.22-13+deb7u1 ii debconf [debconf-2.0]1.5.49 ii libjs-jquery 1.7.2+dfsg-1 ii libjs-jquery-cookie 6-1 ii libjs-jquery-form6-1 ii libjs-jquery-tipsy 6-1 ii mime-support 3.52-1 ii php5 5.4.4-14+deb7u8 ii php5-mysql 5.4.4-14+deb7u8 Versions of packages mediawiki recommends: ii mediawiki-extensions-base 3.5~deb7u1 ii mysql-server 5.5.35+dfsg-0+wheezy1 ii php-wikidiff2 0.0.1+svn109581-1 ii php5-cli 5.4.4-14+deb7u8 ii python 2.7.3-4+deb7u1 Versions of packages mediawiki suggests: pn clamav none pn imagemagick | php5-gd none pn mediawiki-math none pn memcached none -- debconf information: mediawiki/webserver: apache2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#421524: [Pkg-net-snmp-devel] Bug#421524: snmpd uses 100% cpu
On Wed, 2007-05-02 at 12:49 +0200, Jochen Friedrich wrote: Hi Tom, snmpd is running at 100% CPU on 2 of my systems, and will not respond to polls. I have tried the default config file, which has the same effect. I suspect this could be an upstream problem. I must add to the previous bugreport that actual polling of values does work as long as one does not touch the sensitive ones (interface data I think?). Do you have the chance to take 5.3.1-3 (from SID) or 5.4~dfsg-1 (from experimental) and recompile it on Etch? It should recompile without any change. Tried the sid package, same effect. Had previously tried 5.2.1.2-4ubuntu2.1 also, but that didn't help. Now tried the experimental package, same effect. :( Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421524: snmpd uses 100% cpu
Package: snmpd
Version: 5.2.3-7
Severity: grave
Justification: renders package unusable
snmpd is running at 100% CPU on 2 of my systems, and will not respond to
polls. I have tried the default config file, which has the same effect.
After restarting the daemon I can snmpwalk up to (ip's modified):
IP-MIB::ipAdEntBcastAddr.127.0.0.1 = INTEGER: 0
IP-MIB::ipAdEntBcastAddr.172.16.0.1 = INTEGER: 1
IP-MIB::ipAdEntBcastAddr.192.168.35.4 = INTEGER: 1
IP-MIB::ipAdEntBcastAddr.1.2.3.4 = INTEGER: 1
IP-MIB::ipAdEntBcastAddr.1.2.3.5 = INTEGER: 0
IP-MIB::ipAdEntBcastAddr.1.2.3.6 = INTEGER: 0
IP-MIB::ipAdEntBcastAddr.1.2.3.7 = INTEGER: 1
Timeout: No Response from sys.tem.host.name
After this the daemon goes to full CPU in a loop, strace loops this:
gettimeofday({1177879788, 679826}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 14
open(/proc/net/dev, O_RDONLY) = 15
fstat64(15, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f01000
read(15, Inter-| Receive ..., 1024) = 1024
ioctl(14, SIOCGIFADDR, {ifr_name=lo, ifr_addr={AF_INET,
inet_addr(127.0.0.1)}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name=lo, ifr_broadaddr={AF_INET,
inet_addr(0.0.0.0)}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name=lo, ifr_netmask={AF_INET,
inet_addr(255.0.0.0)}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name=lo,
ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name=lo, ifr_hwaddr=00:00:00:00:00:00}) = 0
ioctl(14, SIOCGIFMETRIC, {ifr_name=lo, ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name=lo, ifr_mtu=16436}) = 0
ioctl(14, SIOCGIFADDR, {ifr_name=dummy0, ifr_addr={AF_INET,
inet_addr(172.16.0.1)}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name=dummy0, ifr_broadaddr={AF_INET,
inet_addr(172.16.255.255)}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name=dummy0, ifr_netmask={AF_INET,
inet_addr(255.255.0.0)}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name=dummy0,
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_NOARP}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name=dummy0, ifr_hwaddr=12:8a:75:61:f9:64})
= 0
ioctl(14, SIOCGIFMETRIC, {ifr_name=dummy0, ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name=dummy0, ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name=eth0, ifr_addr={AF_INET,
inet_addr(1.2.3.7)}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name=eth0, ifr_broadaddr={AF_INET,
inet_addr(1.2.3.8)}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name=eth0, ifr_netmask={AF_INET,
inet_addr(255.255.255.128)}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name=eth0,
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name=eth0, ifr_hwaddr=00:e0:81:04:5b:2c}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name=eth0, ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name=eth0, ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name=eth1, ifr_addr={AF_INET,
inet_addr(192.168.35.4)}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name=eth1, ifr_broadaddr={AF_INET,
inet_addr(192.168.35.255)}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name=eth1, ifr_netmask={AF_INET,
inet_addr(255.255.255.0)}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name=eth1,
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name=eth1, ifr_hwaddr=00:e0:81:04:5b:2d}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name=eth1, ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name=eth1, ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name=eth2, ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFBRDADDR, {ifr_name=eth2, ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFNETMASK, {ifr_name=eth2, ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFFLAGS, {ifr_name=eth2,
ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name=eth2, ifr_hwaddr=00:03:47:08:45:ce}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name=eth2, ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name=eth2, ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name=eth3, ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFBRDADDR, {ifr_name=eth3, ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFNETMASK, {ifr_name=eth3, ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFFLAGS, {ifr_name=eth3,
ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name=eth3,
Bug#305216: Patch attached
tags 305216 +patch thanks This will probably occur on everything newer than 2.4.28, I have this on 2.4.30 and 2.6.10. I've created a patch to do this the Correct Way(tm), according to Bertl @ #vserver on OFTC. Maybe the checking of the attributes isn't perfect yet, but it's a start ;) Tom diff -ruN util-vserver-0.30.207.orig/debian/util-vserver.postinst util-vserver-0.30.207/debian/util-vserver.postinst --- util-vserver-0.30.207.orig/debian/util-vserver.postinst 2005-05-21 14:22:52.11441 +0200 +++ util-vserver-0.30.207/debian/util-vserver.postinst 2005-05-21 15:07:56.635260976 +0200 @@ -18,9 +18,15 @@ update-rc.d vprocunhide defaults 25 15 /dev/null fi - chmod 000 /var/lib/vservers/ - chattr +t /var/lib/vservers/ -# setattr --barrier /var/lib/vservers/ || true + # fix older 000 mode to 0700 and older attr +t if present + if [ `ls -ld /var/lib/vservers/|cut -d' ' -f1` == d- -a `lsattr -d /var/lib/vservers/|cut -c16` == t ]; + then + chmod 0700 /var/lib/vservers + chattr -t /var/lib/vservers + fi + + # set chroot barrier + setattr --barrier /var/lib/vservers/*/.. || true # UPGRADE PATH FROM vserver PACKAGE! # It should be fairly fail safe.
Bug#309681: util-vserver: Does not install on Sid
Package: util-vserver Version: 0.30.204-1 Severity: grave Justification: renders package unusable util-vserver does not install on unstable due to dependency on beecrypt2 which seems to have been removed from the debian system (it exists on woody and on sarge). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-deepspace-swsusp2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages util-vserver depends on: ii iproute 20041019-3 Professional tools to control the ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-7GCC support library ii libstdc++5 1:3.3.5-8The GNU Standard C++ Library v3 ii net-tools 1.60-10 The NET-3 networking toolkit -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
