Package: ocsinventory-agent Version: 2:1.1.1-2.3 Severity: important Confirmed on two similar machines (both HP ProLiant DL160 G5), not able to reproduce on about 50 other machines including another ProLiant DL160 G5.
Apparently in our specific configuration, a run of the cron.daily/ocsinventory-agent puts the gbit networkcard in an unusable state. On one machine I have seen the card being in 10 mbit half duplex state and apparently only a reboot will fix it (ifconfig down/up and init.d/networking restart don't seem to work, although ethtool and mii-tool both report the card to be in gbit FD mode afterwards). Unfortunately I'm unable to test further on these two machine as our customer was 'not happy' with the downtime we've already experienced and following policy the package was removed from the system. If needs be, I can reinstall on one machine and take it down for testing, but we prefer not to as it could affect the sites running on them. Before the removal I have reproduced the problem three times (with the first two not having made the connection between the problem and ocsinventory-agent). Everytime, I ran the script from an SSH session, to be thrown out of the session within a few seconds after the script had finished (I had been returned to my shell). By means of a remote KVM I was able to find out the NIC had gone into 10mbit HD mode. Restarting networking did not restore the NIC. Machine has not been down after removing ocsinventory-agent, so it's not hardware. On it's twin machine, I've reinstalled, run the cron script and again, machine was unreachable by network. On this machine though the NIC still reported 1gbit, though I'm not sure I can trust mii-tool (ethtool wasn't installed on this one). ocsinventory-agent has been running on these machines from apr 2009 until beginning of may 2011, a co-worker had turned it off, but I don't have a report of the why and how (and the co-worker is on vacation at the moment). Of the two machines, one is running kernel 2.6.32-5-amd64 and the machine I'm reporting from is still running 2.6.26-2-amd64, so it doesn't seem to be a specific kernel. Also, we have ocsinventory-agent running on about 50 other machines with kernels 2.4 to 2.6.39 without any problem. Even more, we have a machine with the exact same architecture (though with 4GB RAM instead of 2GB) were it doesn't present this problem. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (800, 'stable'), (400, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ocsinventory-agent depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libcompress-zlib-perl 2.024-1 Transitional dummy package for Com ii libnet-ip-perl 1.25-2 Perl extension for manipulating IP ii libnet-ssleay-perl 1.36-1 Perl module for Secure Sockets Lay ii libproc-daemon-perl 0.03-2 Run Perl program as a daemon proce ii libwww-perl 5.836-1 Perl HTTP/WWW client/server librar ii libxml-simple-perl 2.18-3 Perl module for reading and writin ii perl [libcompress-zlib-perl] 5.10.1-17 Larry Wall's Practical Extraction ii po-debconf 1.0.16+nmu1 tool for managing templates file t ii ucf 3.0025+nmu1 Update Configuration File: preserv ocsinventory-agent recommends no packages. Versions of packages ocsinventory-agent suggests: ii dmidecode 2.9-1.2 Dump Desktop Management Interface pn nmap <none> (no description available) ii pciutils 1:3.1.7-6 Linux PCI Utilities pn read-edid <none> (no description available) pn smartmontools <none> (no description available) -- debconf information: ocsinventory-agent/tag: * ocsinventory-agent/method: http * ocsinventory-agent/server: <censored FQDN> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
