[Bug 1546214] [NEW] Docker containers lose their cgroup after systemd reload
Public bug reported: After a Systemd reload & any service restart, docker top no longer show process of containers: To reproduce this issue, do the following step: # docker run -d --name test busybox sleep 1d # docker top test UID PID PPIDC STIME TTY TIMECMD root26416 10721 18:05 ? 00:00:00sleep 1d # systemctl --system daemon-reload && systemctl restart atd.service # docker top test UID PID PPIDC STIME TTY TIMECMD [ no process listed... but sleep is still running] Note: this idea of restarting any service restart come from patch https://lists.freedesktop.org/archives/systemd- devel/2014-September/023276.html (which is applied to Systemd package in Ubuntu) After few searching, this seems to be due to process from the container being moved in other cgroup by Systemd. More details on https://github.com/docker/docker/issues/20152 Depending on version of Systemd (Wily or Xenial), this issue: * Wily: Happend with Docker 1.10 (with default option) * Wily: Does NOT happend with Docker 1.10 and --exec-opt native.cgroupdriver=systemd * Wily: Does NOT happend with Docker 1.9 * Xenial: Does always happend (Docker 1.9, 1.10 with or without native.cgroupdriver=systemd) I don't know if this issue is a Systemd issue, a Docker issue... or in middle. ** Affects: docker.io (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to docker.io in Ubuntu. https://bugs.launchpad.net/bugs/1546214 Title: Docker containers lose their cgroup after systemd reload To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1546214/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1287730] Re: openldap segfault on startup with delta-syncrepl MMR
I've done the following thing to be sure the patch fix the issue: * backported trusty version (2.4.31-1+nmu2ubuntu5) on precise. Run this version, problem still occur * backported trusty + patch (e.g. the 2.4.31-1+nmu2ubuntu5 + the debdiff attached) on precise: Run this version, slapd start successfully. So I confirm that the patch fix this issue. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1287730 Title: openldap segfault on startup with delta-syncrepl MMR To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1287730/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1287730] [NEW] openldap segfault on startup with delta-syncrepl MMR
Public bug reported: We have setup a LDAP master-master replication using delta-sync. On the 2-node cluster, one server fail to restart with a segfault immediately after the startup. Every time we restart the server, it fail with: /# slapd -u openldap -g openldap -d stats -f /etc/ldap/slapd.conf 5315e2a1 @(#) $OpenLDAP: slapd (Sep 19 2013 22:39:38) $ buildd@panlong:/build/buildd/openldap-2.4.28/debian/build/servers/slapd 5315e2a1 hdb_db_open: database cn=accesslog: unclean shutdown detected; attempting recovery. 5315e2a3 hdb_db_open: database dc=qa,dc=example,dc=net: unclean shutdown detected; attempting recovery. 5315e2a6 = bdb_inequality_candidates: (entryCSN) not indexed 5315e2db slapd starting Segmentation fault (core dumped) On syslog: slapd[4506]: segfault at 5e ip 7f13dd954f29 sp 7f13c0a4c800 error 4 in slapd[7f13dd8bb000+128000] Using a coredump and slapd-dbg, the stacktrace of segfault is: #0 syncrepl_op_modify (op=0x7f13c0a4d280, rs=optimized out) at ../../../../servers/slapd/syncrepl.c:2132 #1 0x7f13dd9640fa in overlay_op_walk (op=0x7f13c0a4d280, rs=0x7f13c0a4cd50, which=op_modify, oi=0x7f13de46e2f0, on=optimized out) at ../../../../servers/slapd/backover.c:661 #2 0x7f13dd9642bb in over_op_func (op=0x7f13c0a4d280, rs=optimized out, which=optimized out) at ../../../../servers/slapd/backover.c:723 #3 0x7f13dd956b6f in syncrepl_message_to_op (si=0x7f13de46f390, op=0x7f13c0a4d280, msg=0x7f13a8109660) at ../../../../servers/slapd/syncrepl.c:2316 #4 0x7f13dd95b6ad in do_syncrep2 (si=0x7f13de46f390, op=0x7f13c0a4d280) at ../../../../servers/slapd/syncrepl.c:986 #5 do_syncrepl (ctx=optimized out, arg=0x7f13de46f180) at ../../../../servers/slapd/syncrepl.c:1522 #6 0x7f13dd4559aa in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #7 0x7f13dc38de9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7f13dc0ba3fd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x in ?? () This bug look really like upstream bug ITS#7354 [1] : * failure at same function, at same line (same if ( ml-sml_flags == SLAP_MOD_INTERNAL )) * same wrong value in ml variable (0x40) * same setup as title in ITS ticket (delta-syncrepl with master-master) I don't know how to reproduce the situation, so it's pretty hard to do test. The fix for this issue is very short, it's a one line fix [2]. Note: If the one-line fix is not backported, another solution could be to update openldap version to 2.4.33, which include this fix. Sadly trusty only have 2.4.31. [1]: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7354;selectid=7354;usearchives=1 [2]: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=3f71f756013a61b6a3cf7c529e1ec42675f5e040 ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1287730 Title: openldap segfault on startup with delta-syncrepl MMR To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1287730/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1287730] Re: openldap segfault on startup with delta-syncrepl MMR
I've attached the debdiff patch for trusty. I'm building a backport for precise to test if slapd can start with this patch applied (the server on which the issue occure is running precise). ** Patch added: lp1287730.debdiff https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1287730/+attachment/4006937/+files/lp1287730.debdiff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1287730 Title: openldap segfault on startup with delta-syncrepl MMR To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1287730/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1104915] Re: Wrong expire date in nova-dhcpbridge init output
*** This bug is a duplicate of bug 1103260 *** https://bugs.launchpad.net/bugs/1103260 Yes, the root cause is the same (nova-dhcpbridge init which sent already expired lease). The fix proposed in bug #1103260 should fix this issue. ** This bug has been marked a duplicate of bug 1103260 fixed_ips cannot reliably be released on instance termination -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1104915 Title: Wrong expire date in nova-dhcpbridge init output To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1104915/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1104915] [NEW] Wrong expire date in nova-dhcpbridge init output
Public bug reported: TL; DR; nova-dhcpbridge init generated leases file with instance updated_at instead of fixed_ips updated_at, causing every leases to be expired for several month. So everytime dnsmasq is restarted will sent DHCPNAK the first time a client ask for renew its lease. Long version: dnsmasq expected the leases format to have: * one line per lease * first column is the expire date in second since epoc. * we don’t care about other column for this issue :) This is the case for dnsmasq 2.59 and 2.65 (precise version and raring version). But the output of nova-dhcpbridge init (which is called by dnsmasq to load the leases): 1352420950 xx:xx:3e:01:7d:xx 10.0.0.3 app01.domain * 1352421657 xx:xx:3e:7e:0a:xx 10.0.0.4 app02.domain * [...] So the expire date for those entry are: 9 November 2012 around 1am. The script was run the 25 January 2013 at 9am (UTC). With our lease time of 1 day, we expected an expire date at 25 January 2013 at 10am. So when loaded dnsmasq read all leases and found all leases expired and then discard all leases. This cause dnsmasq to reply DHCPNAK for DHCPREQUEST (since for dnsmasq the lease requested didn’t exist because it’s expired). Hopefully, when client come with a DHCPDISCOVER, dnsmasq will get information form configuration file (/var/lib/nova/networks /nova-brxxx.conf) and create a lease with correct expire time. But this lease is only tracker in memory, so next DHCPREQUEST will work until next restart of dnsmasq. At the end everytime dnsmasq is restarted, when client try to renew a lease it will get a DHCPNAK and it’s interface goes down (loss all IP). Even if the DHCPDISCOVER send right after will re-add the IP, this can trouble some services (in our case, pacemaker which manage a virtual IP). Digging a bit on how nova-dhcpbridge generated the leases file, it seems to come from: * _host_lease function in nova/network/linux_net.py: if data['instance_updated']: timestamp = data['instance_updated'] else: timestamp = data['instance_created'] seconds_since_epoch = calendar.timegm(timestamp.utctimetuple()) return '%d %s %s %s *' % (seconds_since_epoch + FLAGS.dhcp_lease_time, data['vif_address'], data['address'], data['instance_hostname'] or '*') data[‘instance_updated’] is took from table instances, and it match the date seen in output of nova-dhcpbridge init. It’s also the date of creation of our machine (more or less few minutes... probably the end of first boot). From my understanding of how nova-dhcpbridge works, every time dnsmasq reply to a client with a new lease, it call the nova-dhcpbridge script which update the database (table fixed_ips, column updated_at). So I think instead of “instance_updated”, we sould use “fixed_ips.updated_at” when generating the leases. Version of software (Ubuntu version): * Ubuntu 12.04 (precise) amd64 * nova-* 2012.1.3+stable-20120827-4d2a4afe-0ubuntu1 * dnsmasq 2.65-1~precise1 The way leases file are generated by nova-dhcpbridge (_host_lease function in nova/network/linux_net.py) is present in nova git repository at both tag 2012.1.3 (b00f759) and master (97a5274 - dated of Thu Jan 24). ** Affects: nova Importance: Undecided Status: New ** Affects: nova (Ubuntu) Importance: Undecided Status: Confirmed ** Also affects: nova (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1104915 Title: Wrong expire date in nova-dhcpbridge init output To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1104915/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1104915] Re: Wrong expire date in nova-dhcpbridge init output
I see two way for fixing the issue. The first one don't change the db/api, but it's the a very nice fix. The second one seems to be the correct way to fix this issue. patch1.diff : always use time.time() + lease_time to set expiry in nova/network/linux_net.py patch2.diff : add updated (models.FixedIp.updated_at) in data returned by db.api.network_get_associated_fixed_ips, and use this time when generating the leases. ** Patch added: always use time.time() + lease_time to set expiry in nova/network/linux_net.py https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1104915/+attachment/3499726/+files/patch1.diff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1104915 Title: Wrong expire date in nova-dhcpbridge init output To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1104915/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1104915] Re: Wrong expire date in nova-dhcpbridge init output
** Patch added: add updated (models.FixedIp.updated_at) in data returned by db.api.network_get_associated_fixed_ips, and use this time when generating the leases. https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1104915/+attachment/3499727/+files/patch2.diff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1104915 Title: Wrong expire date in nova-dhcpbridge init output To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1104915/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1063806] [NEW] ntp deadlock while exiting and never stop
Public bug reported: Software version: * Description:Ubuntu 12.04.1 LTS * arch : x86_64 * ntp 1:4.2.6.p3+dfsg-1ubuntu3.1 * libc6 2.15-0ubuntu10.2 We hit a strang behavious on some machine, where ntp refuse to quit if stopped right after startup: When running the following command: /etc/init.d/ntp start /etc/init.d/ntp stop ntp still running and ignoring further kill. In syslog we can see the stop is effectivly taken in account: Oct 8 12:45:36 app01 ntpd[16713]: ntpd exiting on signal 15 Sending more kill 16713 do nothing. We have the start and just after stop behavious on our server, because of https://bugs.launchpad.net/nova/+bug/887162. Short summary: dhcp server don't reply until dhcp client lost the IP and request new IP using broadcast request: * (AFAIK) when dhcp don't get answer from DHCP and remove the IP is call a hook which restart ntp (/etc/dhcp/dhclient-exit-hooks.d/ntp) * dhcp retry just after to grab a new IP and get the IP. Interface goes up, a hook restart one more the ntpd (/etc/network/if-up.d/ntpdate) After digging further, I reproduced the issue on my local machine by using a simple script which start and kill ntpd until we reach the issue. Once the issue reproduced I attached gdb to the process and showed stack (see gdb-stack-dbg.txt). Looking to this stack, it seems that the issue is syslog function which is not re-entrant. When signal SIGTERM occure while main thread called syslog, this cause a deadlock. I also attached gdb-stack.txt using packaged ntpd (so no debuging symbol for ntpd function). And I attached ntpd_loop.py : the basic script which start and kill ntpd until it hang. You may need to change the short sleep between start/stop and/or run other resource consuming process on other terminal (I usually do a find /). ** Affects: ntp (Ubuntu) Importance: Undecided Status: New ** Attachment added: gdb info stack during deadlock (with debuging symbols) https://bugs.launchpad.net/bugs/1063806/+attachment/3386608/+files/gdb-stack-dbg.txt -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1063806 Title: ntp deadlock while exiting and never stop To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1063806] Re: ntp deadlock while exiting and never stop
** Attachment added: gdb info stack during deadlock (with packaged ntpd) https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+attachment/3386609/+files/gdb-stack.txt -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1063806 Title: ntp deadlock while exiting and never stop To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1063806] Re: ntp deadlock while exiting and never stop
** Attachment added: script used to show the problem on my workstation https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+attachment/3386619/+files/ntpd_loop.py -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1063806 Title: ntp deadlock while exiting and never stop To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: [SRU] search fail with get_ctrls : controls require LDAPv3
I confirm the version in proposed fix the issue: * before installing proposed version, on fully updated precises : I still reproduce the bug * after installing slapd from proposed : I can't reproduce the bug. Also on this machine, LDAP is used for local authentication, which still work after update (so no regression seen). ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: [SRU] search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
I have found an upstream ticket which seems to be exactly our issue: ITS#7107 [1]. It's fixed on upstream, but was fixed after the release of 2.4.28. It's a one line fix, see git commit [2]. I don't have tested if it effectivelly fix our issue, but description seem very close to our problem. [1]: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7107;selectid=7107 [2]: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=85c1c545f4e20882a2f748fcef5f732ea2d2ecf6 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
** Description changed: - On precise, the slapd daemon return error code 2 - controls require - LDAPv3 to client search. I don't see any reason why this would occure, - because if you run the same command few seconds later, it (may) work. + [IMPACT] - For example, using nss_ldap, when running in a loop id pierref, you - may sometime have fewer group that you would normally have. And few - seconds later, everything go back to normal. + * Any client connecting in LDAPv3 and using v3 specific feature may fail + * This include libnss-ldap (so id user may not return all group). Thus you may login without all your groups and need to logout/login on more time. + * This issue is known and fixed on upsteam, ITS#7107 (commit 85c1c545f4e20882a2f748fcef5f732ea2d2ecf6). - We also have this issue with some other tools, like Confluence - (Atlassian's wiki) and also a internal tools developped in Python. + [TESTCASE] - On client side (confluence), we have - javax.naming.CommunicationException: [LDAP: error code 2 - controls - require LDAPv3]; + To reproduce this issue, you will need to do enougth search some with + version 2, other with version 3 and some control. - On server side, we found the same controls require LDAPv3 returned - with get_ctrl function. I attached log extract of slapd server at - loglevel any. On log I keep one successfull search done by confluence - and one failed search. + Example: - Note: on server log - if I understand log correctly - the client bind - with version 3 of protocol... while error complain about not behind - version 3... - - Version: - - * server : Ubuntu precise 3.2.0-26-generic x86_64, slapd 2.4.28-1.1ubuntu4 - * client 1 : Ubuntu lucid 2.6.32-41-server x86_64, libnss-ldap 264-2ubuntu2, ldap-utils 2.4.21-0ubuntu5.7 - * client 2 : Ubuntu precise 3.2.0-26-virtual x86_64, libnss-ldap 264-2.2ubuntu2, ldap-utils 2.4.28-1.1ubuntu4 - - Their is two LDAP server (replication), I attached configuration of - both. - - I also attached a test_nss.sh which show this bug on client side. + * In terminal A, run: while true; do ldapsearch -h 127.0.0.1 -b o=company uid=dontcare -P 2 /dev/null;sleep 0.1;done + * Let the loop run for some time (it increase change of failure for next step). + * In terminal B, run ldapsearch -h 127.0.0.1 -b o=company uid=dontcare -M. You should not have to run more than 20 times before an error occure. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
debdiff for precise sru. ** Patch added: lp1023025.debdiff https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3228396/+files/lp1023025.debdiff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
debdiff for quantal. ** Patch added: lp-1023025-quantal.debdiff https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3228408/+files/lp-1023025-quantal.debdiff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: [SRU] search fail with get_ctrls : controls require LDAPv3
Great. Thanks for your quick reactivity. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: [SRU] search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
I can reproduce this issue with a simple ldapsearch: ldapsearch -h ldap-1 -b ou=people,o=company -x (((objectClass=posixAccount)(uid=*))(uid=pierref)) -M -v Note: I think the exact query filter doesn't matter, only the -M switch is important. The result when it fail is: ldap_initialize( ldap://ldap-1) filter: (((objectClass=posixAccount)(uid=*))(uid=pierref)) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base ou=people,o=company with scope subtree # filter: (((objectClass=posixAccount)(uid=*))(uid=pierref)) # requesting: ALL # with manageDSAit control # # search result search: 2 result: 2 Protocol error text: controls require LDAPv3 # numResponses: 1 But this don't occure often... running this command every 5 seconds generated only 6 errors in 3 hours. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] [NEW] search fail with get_ctrls : controls require LDAPv3
Public bug reported: On precise, the slapd daemon return error code 2 - controls require LDAPv3 to client search. I don't see any reason why this would occure, because if you run the same command few seconds later, it (may) work. For example, using nss_ldap, when running in a loop id pierref, you may sometime have fewer group that you would normally have. And few seconds later, everything go back to normal. We also have this issue with some other tools, like Confluence (Atlassian's wiki) and also a internal tools developped in Python. On client side (confluence), we have javax.naming.CommunicationException: [LDAP: error code 2 - controls require LDAPv3]; On server side, we found the same controls require LDAPv3 returned with get_ctrl function. I attached log extract of slapd server at loglevel any. On log I keep one successfull search done by confluence and one failed search. Note: on server log - if I understand log correctly - the client bind with version 3 of protocol... while error complain about not behind version 3... Version: * server : Ubuntu precise 3.2.0-26-generic x86_64, slapd 2.4.28-1.1ubuntu4 * client 1 : Ubuntu lucid 2.6.32-41-server x86_64, libnss-ldap 264-2ubuntu2, ldap-utils 2.4.21-0ubuntu5.7 * client 2 : Ubuntu precise 3.2.0-26-virtual x86_64, libnss-ldap 264-2.2ubuntu2, ldap-utils 2.4.28-1.1ubuntu4 Their is two LDAP server (replication), I attached configuration of both. I also attached a test_nss.sh which show this bug on client side. ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
** Attachment added: Log on one of slapd server when bug occure https://bugs.launchpad.net/bugs/1023025/+attachment/3218612/+files/syslog -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
** Attachment added: Configuration of slapd on master https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3218625/+files/slapd-1.conf -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1023025] Re: search fail with get_ctrls : controls require LDAPv3
** Attachment added: Configuration of slapd on slave https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3218626/+files/slapd-2.conf -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1023025 Title: search fail with get_ctrls : controls require LDAPv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 497781] Re: sshd stop on two SIGHUP
Thanks for the patch, with this patch I can't reproduce the bug. I toke the patch, applied it on fresh apt-get source. builded it with a pbuilder, installed the result. With that I was unable to reproduce the problem. Got back to karmic release of openssh and I can reproduce the bug. So the patch effectively resolved my issue. -- sshd stop on two SIGHUP https://bugs.launchpad.net/bugs/497781 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 497781] [NEW] sshd stop on two SIGHUP
Public bug reported: When you send two SIGHUP to sshd (to reload it configuration), sshd simply die. How to reproduce: 1)start an sshd server if you do killall -s SIGHUP sshd. The server restart successfully. 2) To kill sshd with SIGHUP, run killall -s SIGHUP sshd killall -s SIGHUP sshd i.e. run two killall -s SIGHUP sshd at the same time. 3) # ps waux | grep sshd root 19265 0.0 0.0 3352 820 pts/10 S+ 15:42 0:00 grep sshd No sshd running :( I think it's because the second SIGHUP happend before sshd finished his startup. Their is not problem running several killall -s SIGHUP sshd we a little delay (like the time to press up arrow and enter). But two SIGHUP at the same time cause sshd to die nearly everytime. This is an issues because afaik SIGHUP is sent by networking script (ifup ?) when an interface have an IP. On a server with 3 static IP, the sshd process get killed this way. No sshd, not possible to do an ssh on that server. Rebooted the server and everything get fine. ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- sshd stop on two SIGHUP https://bugs.launchpad.net/bugs/497781 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 497781] Re: sshd stop on two SIGHUP
Forget to tell the version affected: This was tester on jaunty (with the killall -s SIGHUP). The server is on hardy. So hardy and jaunty are affected. -- sshd stop on two SIGHUP https://bugs.launchpad.net/bugs/497781 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 222804] Re: [SRU] fail2ban fails to start after reboot
+1 Also work for me. Thanks -- [SRU] fail2ban fails to start after reboot https://bugs.launchpad.net/bugs/222804 You received this bug notification because you are a member of Ubuntu Server Team, which is a direct subscriber. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
