Bug#773204: ifupdown with ucarp does not recover after ethernet unplugged
Package: ifupdown Version: 0.7.8 Severity: important Dear Maintainer, Where VLANS are used in conjunction with ucarp, a loss of power to the ethernet port will trigger ucarp to remove the $dev:ucarp alias interfaces, but it will also remove all the VLAN inferfaces (this is related to bug 742018). This will happen if the switch is rebooted, the port turned off, or the cable unplugged. restarting networking did not help. I did not test specifically killing ucarp before trying. -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (350, '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 ifupdown depends on: ii dpkg 1.16.15 ii initscripts 2.88dsf-41+deb7u1 ii iproute 20120521-3+b3 ii libc62.13-38+deb7u6 ii lsb-base 4.1+Debian8+deb7u1 ifupdown recommends no packages. Versions of packages ifupdown suggests: ii isc-dhcp-client [dhcp-client] 4.2.2.dfsg.1-5+deb70u6 ii net-tools 1.60-24.2 pn ppp pn rdnssd -- 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#731795: failures under load with slapd in wheezy
dpkg -l slapd ii slapd2.4.39-1 amd64 OpenLDAP server (slapd) Test script, run from another system: for i in `seq 2048`; do ldapsearch -x -H ldaps://ldapm1.test.realityfailure.org -b "ou=people,dc=test,dc=realityfailure,dc=org" & done 2>&1 | grep -i sasl I've bumped it up to 4096, but am currently hitting the physical limits of my virtuals in testing. In other words, I believe an update to 2.4.39 resolved the specific issue I encountered. On 08/06/2014 01:01 AM, Ryan Tandy wrote: > tags 731795 + moreinfo > thanks > > Hi John, > > I've tried a couple of times now to reproduce this bug in wheezy, with > no luck. I've tried forking many ldapsearch instances like you > suggested, as well as the slapd-mtread tool from the test suite, and > the only failures I get are when slapd hits the open files limit (even > with that increased to 65536 or higher). > > Is it possible for you to try the 2.4.39 package from testing and > confirm whether the problem is solved? Otherwise, any more information > you can provide about a scenario that reproduces this would be helpful. > > thanks, > Ryan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731795: failures under load with slapd in wheezy
Perhaps some of this background information will be useful: We did not see this issue in slapd 2.4.23-7.3, in squeeze. The number of unique entries in the LDAP database do not appear to affect where it starts dropping connections, as we've tested with 2 to over 500 unique accounts. The number of entries searched for do not seem to affect where connections start failing, as tests were run on one particular DN, and on up to 15 unique DNs. This can be reproduced through a simple while loop in shell, using the ldapsearch command line tools. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731795: failures under load with slapd in wheezy
Package: slapd Version: 2.4.31-1+nmu2 Placing the slapd server under load, at somewhere between 512 and 1024 simultaneous connections (using TLS, may be higher unencrypted), you will end up see variations of: "ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)" Under simple tests, I've seen these occur for anywhere between 5 and 50% of the connection attempts. I have been able to replicate this on systems ranging from a VM with 256M of ram to an 8GB physical server to a 24GB 12 CPU system (2 physical, 6 cores each), and it all fails in the same range of connections. Recommendation: Upgrade to slapd-2.4.38 in jessie and wheezy-backports. According to the openldap changelogs (http://www.openldap.org/software/release/changes.html), the following fix was included in openldap 2.4.32: "Fixed slapd-bdb/hdb cache hang under high load (ITS#7222)" I downloaded and compiled openldap 2.4.38 on a 256MB VM system, using the same configuration options Debian uses. Under current tests, it has survived over 16k connections without any errors. This is a factor of 4, and still going. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
