[Bug 1047384] Re: System Encryption Password set before setting keyboard locale
I can confirm there is a bug in 17.10. It's probably another bug but has
the same symptom: LUKS passphrase is prompted in qwerty and not with
user defined keymap.
This is a "new" bug in 17.10, it worked in previous release.
A workaround is to copy /etc/console-setup/cached_UTF-8_del.kmap.gz (or
similar) to /etc/console-setup/cached.kmap.gz and running update-
initramfs -u
To reproduce this issue, do a *fresh* install of artful from server ISO
(desktop not tested, maybe also affected), configure the keyboard layout to
non-qwerty during install and use encrypted disk.
During boot, when prompted for luks passphrase the keyboard is in qwerty. If
the user can enter its passphrase on a qwerty keyboard, the keymap is the
correct one in the console. The issue seems to be only during initramfs.
I got the idea to copy cached.kmap.gz from Debian bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619711
>From my understanding this bug is a mismatch between the behavior of
>console-setup and initramfs-tools.
On Debian this seems fixed by hooks/keymap from initramfs-tools (not present in
Ubuntu package).
On Ubuntu it seems still expected that /etc/console-setup/cached.kmap.gz
is generated but it's no longer the case since artful:
$ debdiff console-setup_1.142ubuntu5.dsc console-setup_1.166ubuntu7.dsc:
[...]
-cached=/etc/console-setup/cached$VARIANT.kmap.gz
+cached=/etc/console-setup/cached_${CHARMAP}_$backspace$VARIANT.kmap.gz
[...]
** Bug watch added: Debian Bug tracker #619711
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619711
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1047384
Title:
System Encryption Password set before setting keyboard locale
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1047384/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1518457] Re: kswapd0 100% CPU usage
If the verification apply also on 16.04, it does fix the issue. We had a server that triggered the bug at least once a day (I suspect unattended-upgrade run every morning to trigger it). Since the upgrade - 2 days and half ago - the server had no issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1518457 Title: kswapd0 100% CPU usage To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1518457/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1415880] Re: 14e4:4365 bcmwl-kernel source: fix for null pointer crash
** Attachment added: Kernel panic when suspending https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+attachment/4401633/+files/pierref-crash.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1415880 Title: 14e4:4365 bcmwl-kernel source: fix for null pointer crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1415880] Re: 14e4:4365 bcmwl-kernel source: fix for null pointer crash
I have null pointer exception on a XPS 13 (9343) which trigger a kernel panic when I suspend the laptop. I can reproduce the issue nearly all times (3 / 4 tries), for this I need to generate network traffic (looking a video on Internet seem to be enough). After applying the patch mentioned above, I not longer have such kernel panic (done 6 tries without any kernel panic). So that patch seems to solve my kernel panic issue when suspending laptop. I will attach the debdiff I used to apply the patch. Without the patch (with bcmwl-kernel-source 6.30.223.248+bdcom- 0ubuntu2), I could product a kernel panic by doing: * Have network load (watching video on internet, downloading something, ...) * Suspend the laptop. On my test I did it with systemctl suspend from tty1 to capture the Call trace. System information: * Hardware : Dell XPS 13 (9343) * Ubuntu 15.04 amd64 * Bios A03 03/25/2015 * bcmwl-kernel-source 6.30.223.248+bdcom-0ubuntu2 (so wifi is using module wl) * lspci : 02:00.0 Network controller: Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter (rev 03) I will also attach picture of the screen after a crash + partial transcript the of kernel panic (see picture for the full information). ** Patch added: Patch to fix suspend kernel panic https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+attachment/4401631/+files/lp1415880.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1415880 Title: 14e4:4365 bcmwl-kernel source: fix for null pointer crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1415880] Re: 14e4:4365 bcmwl-kernel source: fix for null pointer crash
** Attachment added: Kernel panic when suspending https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+attachment/4401634/+files/pierref-crash.jpg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1415880 Title: 14e4:4365 bcmwl-kernel source: fix for null pointer crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1415880] Re: 14e4:4365 bcmwl-kernel source: fix for null pointer crash
** Attachment added: lspci + software version https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+attachment/4401636/+files/pierref-system-info.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1415880 Title: 14e4:4365 bcmwl-kernel source: fix for null pointer crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1415880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I see that trusty has now a kernel with the fix included: $ cat changelog.Debian linux (3.13.0-21.43) trusty; urgency=low [...] [ Tetsuo Handa ] * SAUCE: kthread: Do not leave kthread_create() immediately upon SIGKILL. [...] After a apt-get dist-upgrade to this kernel, I've successfully booted the server 5 times. So this kernel fix the issue. Thanks all for your work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I've tested this new kernel, it boot without issue on the server (as usual, I booted three time the kernel to make it always works well). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Joseph, kernel freeze is planed in 7 days, which will arrive very fast. Do you think we could have a fix committed before this deadline ? I still didn't tested the firmware upgrade. I didn't tested it to keep a machine which exhibit the bug... upgrading firmware is okay with a local machine, but always trickier with remote server :( If their is something I can do for this issue, please tell me. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I've tested with kernel from comment #56. The kernel generated too much logs for IPMI serial console (which generated too much garbage), so I switched to a real serial console (and at 115kbauds). I've attached a archive with 3 runs (the last run it the most interesting I think): First run with serial console and a bigger kernel log buffer (log_buf_len=8M). The hope with larger log buffer was to catch full kernel message with dmesg once server is running. Sadly, after about 30 minutes, server was still printing stacks. Serial console capture attached under name 01-serial-capture-large-buffer.txt Second run, still with serial console but with default kernel log (no log_buf_len) This time, kernel booted fine (with exception to disk beeing discovered after rootdelay, but a ctrl+d resumed the boot process). Note: this boot generated WAY less message and booted. The only change is the log_buf_len=8M present or not. Serial console capture attached under name 02-serial-capture-default-buffer.txt Third run, this time with serial console disabled and very large kernel log buffer (log_buf_len=32M). Probably the most interesting one, dmesg was complete (include very first messages). It is 12 MB large ! Server booted without any issue (disk detected before the end of rootdelay). ** Attachment added: Logs when running kernel from comment #56 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4033864/+files/logs-3.14.0-031400rc7.201403191557.tar.xz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Applied patch on tag v3.14-rc6 (fa389e2), run kernel 4 four times, all worked. We seen on output (full output attached): [5.537193] mousedev: PS/2 mouse device common for all mice [ [9.776032] floppy0: no floppy controllers found [ 36.823538] Ignored SIGKILL by systemd-udevd [ 38.356082] scsi4 : ioc0: LSISAS1068E B3, FwRev=00192f00h, Ports=1, MaxQ=266, IRQ=16 [ 38.408276] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 9, phy 0, sas_addr 0x5000cca00f2e18fd [...] ** Attachment added: serial-output-patch-comment51.txt https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4031962/+files/serial-output-patch-comment51.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I've tested the following: * v3.14-rc6-trusty from comment #38 : still fail with same error. * Kernel 786235eeba0e1e85e5cbbb9f97d1087ad03dfa21 with patch check-sigkill : still got the fail to spawn thread. I will attach full output from serial console. * Kernel 786235eeba0e1e85e5cbbb9f97d1087ad03dfa21 with patch kthread-defer-leaving.patch : also fail, but this time their is no error about failure to spawn thread. Only systemd-udevd blocked for more that 120 seconds. Also ouput of serial console attached. Note: on second console output, command result from ps is not complet, serial console seem to discard output when we generate it too fast. ** Attachment added: Console output with check-sigkill patch applied on 786235ee https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4026608/+files/serial-ouput-patch-check-sigkill.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
** Attachment added: Console output with kthread-defer-leaving patch applied on 786235ee https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4026609/+files/serial-ouput-patch-kthread-defer-leaving.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Yes, it is working! With this new patch applied (on 786235ee), server boot without any issue. I've attached the console ouput (which show no error). As for other test, I've booter 5 times on this kernel to be sure it was not by luck that it work. Thanks for this fix. ** Attachment added: Console output with kthread-defer-leaving v2 patch applied on 786235ee https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4026655/+files/serial-ouput-patch-kthread-defer-leaving2.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I've tested the final patch againt both 786235ee and tag v3.14-rc6 (fa389e22). It still works. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
With few hopes, I've tried the latest kernel from: * trusty: linux 3.13.0-16.36 (linux-image-3.13.0-16-generic) * trusty-proposed (downloaded from launchpad directly) : linux 3.13.0-17.37 Both still have the bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
If it help, I've done another change (against git hash 786235ee): diff --git a/kernel/kthread.c b/kernel/kthread.c index b5ae3ee..25a4780 100644 --- a/kernel/kthread.c +++ b/kernel/kthread.c @@ -298,7 +298,7 @@ struct task_struct *kthread_create_on_node(int (*threadfn)(void *data), * that thread. */ if (xchg(create-done, NULL)) - return ERR_PTR(-ENOMEM); + return ERR_PTR(-42); /* * kthreadd (or new kernel thread) will call complete() * shortly. So, depending on error (-12 / -ENOMEM or -42) we could know which return triggered the bug. Result is: [ 37.607981] scsi4: error handler thread failed to spawn, error = -42 To make sure the race condition do not affect which error is returned, I've booted 5 times that kernel. Each time I get error = -42. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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] 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
By more testing, you just mean reboot several time on this kernel to check that the isssue do not appear sometime ? During my bisect, I always booted 3 times on good kernel to make sure it was not by luck that the kernel worked. I also booted three time the kernel from comment #28. To double check, I just booted 5 times with this kernel and all 5 times worked. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
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). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Any update ? If i can help for something tell me, but I don't know kernel and can't do debuging of it by myself. I've tried to identify which ENOMEM cause the issue by added the printk (one before the first ENOMEM, one before the second ENOMEM, one after both ENOMEM)... but with just this change bug no longer occure ! I've already suspected that this bug is due to some race-condition because it seems to occure nearly everytime with rootdelay + serial console, and seems to sometime success when using neither rootdelay nor serial console. I've attached the diff of printk I've added. ** Patch added: printk.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4005322/+files/printk.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Yes, this version is working: Linux version 3.13.0-12-generic (root@gomeisa) (gcc version 4.8.2 (Ubuntu 4.8.2-15ubuntu3) ) #32 SMP Mon Feb 24 18:50:37 UTC 2014 (Ubuntu 3.13.0-12.32-generic 3.13.4) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Bisect finished. The first bad commit is 786235eeba0e1e85e5cbbb9f97d1087ad03dfa21. It seem more likely as this commit concerne kthread (and the first error is scsi4: error handler thread failed to spawn, error = -12). I also attach my bisect log if needed. ** Attachment added: bisect.log https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/3994538/+files/bisect.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Ok, I've restarted a bisect without limitation on driver/scsi (git bisect start v3.13-rc1 v3.12). Git tell me it's 13 steps, will took some time, but during middle of next week we should have the bad commit. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I can not test this kernel, it was only build for i386. The server is installed with amd64 :( Because of timezone difference we can only test one kernel per day, to speed up the bisect, I've done one by myself, the result is the following: $ git bisect log # bad: [6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae] Linux 3.13-rc1 # good: [5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52] Linux 3.12 git bisect start 'v3.13-rc1' 'v3.12' '--' 'drivers/scsi' # good: [53151bbb83f11b358ac94eddd81347c581dc51ea] [SCSI] lpfc 8.3.43: Fixed not processing task management IOCB response status git bisect good 53151bbb83f11b358ac94eddd81347c581dc51ea # good: [323f6226a816f0b01514d25fba5529e0e68636c3] Merge tag 'fcoe-3.13' into for-linus git bisect good 323f6226a816f0b01514d25fba5529e0e68636c3 [Above this point, I didn't build kernel. It was the result from your kernel. Bellow the result are from kernel compiled by myself] # bad: [2f466d33f5f60542d3d82c0477de5863b22c94b9] Merge tag 'pci-v3.13-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci git bisect bad 2f466d33f5f60542d3d82c0477de5863b22c94b9 # bad: [0910c0bdf7c291a41bc21e40a97389c9d4c1960d] Merge branch 'for-3.13/core' of git://git.kernel.dk/linux-block git bisect bad 0910c0bdf7c291a41bc21e40a97389c9d4c1960d # good: [0324e74534241f3f00910ec04ef67de1fe1542f4] Merge tag 'driver-core-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect good 0324e74534241f3f00910ec04ef67de1fe1542f4 # good: [e37459b8e2c7db6735e39e019e448b76e5e77647] Merge branch 'blk-mq/core' into for-3.13/core git bisect good e37459b8e2c7db6735e39e019e448b76e5e77647 # bad: [8ceafbfa91ffbdbb2afaea5c24ccb519ffb8b587] Merge branch 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-arm git bisect bad 8ceafbfa91ffbdbb2afaea5c24ccb519ffb8b587 # good: [7d35496dd98229cdf923238367fd3b3833fbde52] ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations git bisect good 7d35496dd98229cdf923238367fd3b3833fbde52 # first bad commit: [8ceafbfa91ffbdbb2afaea5c24ccb519ffb8b587] Merge branch 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-arm From my bisect, the commit which introduced the error is 8ceafbfa91ffbdbb2afaea5c24ccb519ffb8b587. For information, to build the kernel I did the following: git remote add ubuntu-trusty git://kernel.ubuntu.com/ubuntu/ubuntu- trusty.git git checkout ubuntu-trusty/master -- debian git checkout ubuntu-trusty/master -- debian.master fakeroot debian/rules clean defaultconfigs fakeroot debian/rules binary-generic skipmodule=true Build area was cleaned after each build. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
This kernel version is also good: Linux version 3.12.0-031200rc5-generic (jsalisbury@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201402131403 SMP Thu Feb 13 19:04:57 UTC 2014 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Tested this kernel. It is NOT working, it has the issue. Extract of console log: [...] Linux version 3.12.0-031200-generic (jsalisbury@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201402101715 SMP Thu Feb 13 14:58:01 UTC 2014 [...] [ 42.455969] scsi4: error handler thread failed to spawn, error = -12 [ 42.541170] mptsas: ioc0: WARNING - Unable to register controller with SCSI subsystem [ 42.630361] BUG: unable to handle kernel NULL pointer dereference at 0060 [...] -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
This one is good, it is working: [...] Linux version 3.12.0-031200rc5-generic (jsalisbury@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201402131150 SMP Thu Feb 13 16:54:49 UTC 2014 [...] -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
None of them worked. All had the same issue. Tested: * v3.13-rc3 * v3.13-rc2 * v3.13-rc1 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc1-trusty/) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Yes, I confirm that 3.12-saucy works. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
I booted kernel with following common option : ro console=tty0 console=ttyS1,57600. When booted with rootdelay, it's rootdelay=45. The result are the following: * 3.13.0-7-generic, rootdelay = error * 3.13.0-7-generic, no rootdelay = Ok * 3.6, rootdelay = Ok * 3.12, rootdelay = Ok, tested twice. * 3.13.0-6-generic, rootdelay = error * 3.13.0-6-generic, no rootdelay = Error... then on next try Ok. The error is due to some race condition ? * Tested once more time 3.12 with rootdelay = Ok. * 3.13.0-7-generic, no rootdelay = Ok So the issue is between 3.12 and 3.13. Also on 3.13 with same condition (console=tty0 console=ttyS1,57600), sometime we got the error, sometime we didn't get the error. We always got the error with rootdelay set. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
It still occure with 3.14.0-031400rc1-generic. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
** Attachment added: lspci -vnn on the server https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/3970067/+files/lspci.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] [NEW] Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
Public bug reported: We have recently upgraded an Dell R300 server to Trusty (was running fine in precise), and after upgrade it fail to boot. It is an issue with the SAS controller during the initilisation. It fail to detect the disk, we have the following error in console log: [ 36.539955] scsi4: error handler thread failed to spawn, error = -12 [ 36.552694] mptsas: ioc0: WARNING - Unable to register controller with SCSI subsystem After this error, initramfs drop to a shell complaining that rootfs is not found. No disk is seen at all (cat /proc/partition only show sr0 - cdrom drive). We have this issue with two different server (both R300, both Dell SAS 6/iR controller and same hardware). We don't have this issue with another Dell server (R310, Dell PERC H200). We also tester with old kernel (generic, 3.2.0-58.88), it is working. Those server need a greater rootdelay (probably #579572), so we have rootdelay=45. If we remove rootdelay=45, then disk are correctly recognized ! (but few second too late, initramfs dropped to a shell. Pressing control-D resume normal boot) So the issue is that with the (mandatory) rootdelay greater that 30 (default value I think), the disk are not detected due to the error shown above. This is a regression since those server worked in precise (and work with precise old kernel). System information * Dell R300 with Dell SAS 6/iR controller * Ubuntu Trusty Tahr (14.04) * Running arch: x86_64 * Kernel version: 3.13.0-7-generic (dpkg version : 3.13.0-7.25) * Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.0-7-generic root=UUID=174e14b5-46fc-479b-9f94-05cb33c75ac9 ro rootdelay=45 console=tty0 console=ttyS1,57600 quiet * uname -a: Linux frtls-perf01 3.13.0-7-generic #25-Ubuntu SMP Tue Feb 4 10:19:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Attached files: * console output when error occure. * dmesg when system boot (no rootdelay, need to press control-d during initramfs boot) * lspci -vnn Tell me if you need more informations. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: console output (initramfs) when error occure https://bugs.launchpad.net/bugs/1276705/+attachment/3970065/+files/console.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1276705] Re: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)
** Attachment added: dmesg from a running system (no rootdelay, press control-d in initramfs) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/3970066/+files/dmesg.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1276705 Title: Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1264971] Re: Logrotate is not working correctly
I tested on our server with a logrotate whose copytruncate is replaced with nocreate. It work as expected: file is moved and not re-created, thus carbon detect the logrotate and write to new log file (without a bunch of NUL ascii character). I attached the new debdiff with the nocreate option set. ** Patch added: updated debdiff https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+attachment/3948549/+files/lp1264971.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1264971 Title: Logrotate is not working correctly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1264971] Re: Logrotate is not working correctly
Removing copytruncate wasn't enough ... missed that /etc/logrotate.conf enable create by default. Also sharedscripts imply create Currently logfile are only moved and carbon continue to write in that file (i.e. it write in query.log.1, console.log.1). I'm trying with explicit nocreate added and keep you informed if it's working. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1264971 Title: Logrotate is not working correctly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1264971] Re: Logrotate is not working correctly
Tested on Debian unstable and reported bug on Debian BTS : #733856. ** Bug watch added: Debian Bug tracker #733856 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733856 ** Also affects: graphite-carbon (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733856 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1264971 Title: Logrotate is not working correctly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1264971] [NEW] Logrotate is not working correctly
Public bug reported: Current logrotate script use copytruncate mode, but carbon-cache do not behave well with such mode : after rotation logfile will start with huge hole full of NULL character. To reproduce, you can: * install package (tested with 0.9.12-1 on Ubuntu saucy 13.10) * Start graphite-carbon (edit /etc/default/graphite-carbon to enable startup, start it with /etc/init.d/graphite-carbon) * Create some message on logfile, example for listener.log, just open/close a connection on port 2003 * Simulate logrotate action (cp listener.log listener.log.1 echo -n listener.log) * Re-create some message on logfile. * See that log file start with NULL character It seems that code support external log rotation if the file is only moved. From file lib/carbon/log.py, we can see that if log file no longer exist it will be re-opened: def write(self, data): if not self.enableRotation: if not exists(self.path): self.reopen() Where self.enableRotation is the carbon's internal log rotation disabled by Debian packaging. So a solution could be to disable copytruncate in logrotate. The default mode of logrotate, if I'm not wrong, is to move the file and no recreating a new file. Thus carbon-cache will detect that logfile no longer exist and re-open it. ** Affects: graphite-carbon (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1264971 Title: Logrotate is not working correctly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1264971] Re: Logrotate is not working correctly
Debdiff for trusty ** Patch added: lp1264971.debdiff https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+attachment/3937733/+files/lp1264971.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1264971 Title: Logrotate is not working correctly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/1264971/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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] 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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: [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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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] 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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] 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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 243393] Re: dmesg is flooded with warnings in kvm/mmu.c
I had the same problem here: host running on hardy, 64bits with kvm version 1:62+dfsg-0ubuntu8.2 kernel 2.6.24-24-server Memory: 16 Gb guest running on hardy, 32bits kernel 2.6.24-24-virtual. Memory: 3Gb guest dmesg contains nothing special, host dmesg contains lots of : [183668.247232] WARNING: at /build/buildd/linux-2.6.24/arch/x86/kvm/mmu.c:378 account_shadowed() [183668.247236] Pid: 14823, comm: kvm Not tainted 2.6.24-24-server #1 [183668.247237] [183668.247237] Call Trace: [183668.247246] [882fde69] :kvm:gfn_to_memslot+0x9/0x20 ... I also tried to reduce memory to 1Gb, the error still happen, but with 512Mb we don't get any error. This problem is fixed in latter ubuntu release (at least in Jaunty), the patch which fixed this is likely this one: http://kerneltrap.org/mailarchive/git-commits-head/2008/5/5/1720244 It would be nice to apply this change on hardy as this generate more than 3Gb of log per day ! -- dmesg is flooded with warnings in kvm/mmu.c https://bugs.launchpad.net/bugs/243393 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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
[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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 88136] ejabberd password all readable
Public bug reported: Binary package hint: ejabberd I'm using dapper and I have installed ejabberd. I see that ejabber store password in plaintext on this file : /var/lib/ejabberd/passwd.DCD (this seems normal and it's not the subjet of this bug report) But the permision of this file and the directory allow all users to read the password. Removing reading and execution on the directory /var/lib/ejabberd solve the problem, ejabberd still works and only ejabberd can read the file. ls -ld /var/lib/ejabberd: drwxr-xr-x 2 ejabberd ejabberd 4096 2007-02-26 21:56 /var/lib/ejabberd/ ls -l /var/lib/ejabberd/password.DCD: -rw-r--r-- 1 ejabberd ejabberd 767 2007-02-26 21:32 /var/lib/ejabberd/passwd.DCD thePassword is the password of a testing account. grep was done with a unix user account (works even with nobody) grep thePassword /var/lib/ejabberd/password.DCD: Binary file passwd.DCD matches (it's binary but password and [EMAIL PROTECTED] are clear text) ** Affects: ejabberd (Ubuntu) Importance: Undecided Status: Unconfirmed -- ejabberd password all readable https://launchpad.net/bugs/88136 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
