Bug#1041533: Also affects Ganeti Package
This issue also affects the Ganeti Package indirectly - it does not allow the user to disable the vncpasswd file/configuration which results in unbootable instances after an Upgrade to Debian Bookworm: gnt-instance start xen-test-instance01 Waiting for job 258 for xen-test-instance01.staging.ganeti.org ... Job 258 for xen-test-instance01.staging.ganeti.org has failed: Failure: command execution error: Could not start instance 'xen-test-instance01.staging.ganeti.org': Hypervisor error: Failed to start instance xen-test-instance01.staging.ganeti.org: exited with exit code 3 (Parsing config from /etc/xen/xen-test-instance01.staging.ganeti.org WARNING: you seem to be using "kernel" directive to override HVM guest firmware. Ignore that. Use "firmware_override" instead if you really want a non-default firmware WARNING: ignoring device_model directive. WARNING: Use "device_model_override" instead if you really want a non-default device_model libxl: error: libxl_qmp.c:1399:qmp_ev_fd_callback: Domain 9:error on QMP socket: Connection reset by peer libxl: error: libxl_qmp.c:1438:qmp_ev_fd_callback: Domain 9:Error happened with the QMP connection to QEMU libxl: error: libxl_dm.c:3371:device_model_postconfig_done: Domain 9:Post DM startup configs failed, rc=-26 libxl: error: libxl_create.c:1896:domcreate_devmodel_started: Domain 9:device model did not start: -26 libxl: error: libxl_aoutils.c:646:libxl__kill_xs_path: Device Model already exited libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 9:Non-existant domain libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 9:Unable to destroy guest libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 9:Destruction of domain failed ). Moved config file to /var/log/ganeti/xen/xen-test-instance01.staging.ganeti.org-2024-05-16_16_14_29 -- Rudolph Bott - b...@sipgate.de Telefon: +49 (0)211-63 55 55-55 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.co.uk
Bug#1021703: slapd crashes when too many clients connect in a short period of time.
Hi Harald,
thank you for looking into this.
On Mon, Oct 24, 2022 at 4:36 PM Harald Welte wrote:
> some miscellaneous questions that come to my mind after reading the bug
> report
>
> * if the slapd is hanging, what does a 'strace' on the PID of the slapd
> process tell you?
>
Unfortunatly I was not able to reproduce the 'hanging slapd' today, it
always crashed directly with the aforementioned assertion error.
* what is the rate of new client connections the triggers the problem for
> you (you can for example check the number of TCP SYN per second to the LDAP
> port via pcap file)?
>
If I have interpreted the tcpdump data correctly, the issue seems to hit
at around 200 connections per second, maybe less.
* can you reproduce the problem irrespective of GSSAPI/kerberos?
>
I tried to do so by manipulating the reproducer python script to use
anonymous bind (e.g. use con.bind_s('', '') instead of SASL interactive
bind). While crashing slapd reliably with two or three machines running the
script at the same time using GSSAPI auth, I could not get it to crash
using simple/anyonmous bind. It very well may have something to do with the
delays introduced by the GSSAPI handshake (e.g. DNS lookups for service/TXT
records, Kerberos communication etc.).
--
Rudolph Bott - b...@sipgate.de
Telefon: +49 (0)211-63 55 55-55
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.co.uk
Bug#1021703: slapd crashes when too many clients connect in a short period of time.
We tried reproducing the issue with debug level set to "any" to add more debug/log output to this bug. However, with debug logging enabled it does not crash any more. We doubled the number of machines running the "stress script", but still could not reproduce the crash. With logging disabled (or set to something less verbose like 'stats') it crashes reliably. It seems the debug logging affects slapd's speed enough to not trigger the bug (probably a race somewhere in the code then). Cheers, Rudi -- Rudolph Bott - b...@sipgate.de Telefon: +49 (0)211-63 55 55-55 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.co.uk
Bug#971273: libc6-dev: libpthread_nonshared.a missing from libc6-dev (breaks Oracle 19c setup)
Package: libc6-dev Severity: normal Dear Maintainer, we are trying to install an Oracle 19c database server on a Debian Buster system. Installing this piece of software has not always been easy on Debian systems (as it is not an officially supported by Oracle), but worked more or less painless. However, installation of the current version 19c (and probably older versions as well) breaks as the installer is trying to link against 'libpthread_nonshared.a', which has been removed a while ago from the Debian packages. The same has happened to e.g. the Fedora glibc packages, but an additional compat package has been released to restore the 'libpthread_nonshared.a' file to support installations of Oracle databases (see [1]). Would this also work for Debian or is there any other possible solution? If you need more information, we are happy to provide it. Just let us know! Regards, Rudolph Bott [1] https://bugzilla.redhat.com/show_bug.cgi?id=1625507 -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (550, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#958926: qemu-kvm: QEMU KVM live migration crashes when the VM is in booting state
Package: qemu-kvm Version: 1:4.2-7 Severity: important Dear Maintainer, During a QEMU KVM live migration the sending process crashes if the VM is currently in a booting state (and possibly also during a 'soft' reboot from inside the VM). This has been fixed upstream: https://github.com/qemu/qemu/commit/9b3a31c745b61758aaa5466a3a9fc0526d409188 There are also bug reports available for this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1771032 https://bugzilla.redhat.com/show_bug.cgi?id=1772774 I stumbled over this problem while testing latest builds of Ganeti (https://github.com/ganeti/ganeti) on Debian Bullseye and Ubuntu Focal Fossa which both ship qemu 4.2. The Ganeti QA suite runs a series of tests against a cluster and issues a VM failover (QEMU shutdown on Node A and start on Node B) directly followed by a live migration (QEMU live migration from Node B to Node A). The sending QEMU process dies with this error message: qemu-system-x86_64: /build/qemu-oknQD6/qemu-4.2/accel/kvm/kvm-all.c:653: kvm_log_clear_one_slot: Assertion `mem->dirty_bmap' failed. If you add 'sleep 2' between the reboot and the live migration instructions everything works fine, because the QEMU VM has left the booting state by the time the live migration starts. From a Ganeti point of view, this only happens when using the "sharedfile" storage backend. When you use e.g. DRBD, the Ganeti commands take a bit longer to finish which gives the VM enough time to boot up. For further reference, the same issue has been opened (and fixed) for the respective Ubuntu package: https://bugs.launchpad.net/qemu-kvm/+bug/1872107 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-kvm depends on: ii qemu-system-x86 1:4.2-7 qemu-kvm recommends no packages. qemu-kvm suggests no packages. -- debconf information excluded
