Bug#1056193: closed by Debian FTP Masters (reply to Patrick Matthäi ) (Bug#1056193: fixed in glusterfs 11.1-2)
Thanks for the fix! It seems to me that a warning about the situation needs to be added to the bookworm release notes, and/or apt-listchanges, because people might upgrade to bookworm as I recently did and find their configuration broken. The same would need to be done for trixie since anybody successfully running the bookworm version will find their configuration broken when upgrading to trixie.
Bug#1056193: glusterfs-client: GlusterFS SSL path changed without warning in Bookworm
Package: glusterfs-client Version: 10.3-5 Severity: normal Dear Maintainer, I have a bullseye GlusterFS cluster which uses SSL/TLS. Three machines have a replica of the data, and an additional one merely mounts the cluster without local storage for purposes of backing it up. I recently upgraded the backup machine to bookworm. Suddenly I was unable to mount the cluster. The key error in the logs was: E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our cert at /usr/lib/ssl/glusterfs.pem /usr/lib/ssl/ is a strange path. As far as I can tell, the correct path is /etc/ssl/. Creating three symlinks fixed the problem and allowed the cluster to be mounted: /usr/lib/ssl/glusterfs.ca -> /etc/ssl/glusterfs.ca /usr/lib/ssl/glusterfs.pem -> /etc/ssl/glusterfs.pem /usr/lib/ssl/glusterfs.key -> /etc/ssl/glusterfs.key Taking another look at the apt-listchanges output for the upgrade, there is nothing from any gluster package. This leads me to believe that the changing of this path was unintentional and is a bug. Not sure what's the best thing to do about it at this point, since fixing it would break people's existing bookworm configurations. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages glusterfs-client depends on: ii glusterfs-common 10.3-5 ii libc6 2.36-9+deb12u3 ii python3 3.11.2-1+b1 glusterfs-client recommends no packages. glusterfs-client suggests no packages. -- no debconf information
Bug#1037063: libxml-libxml-perl: Seemingly incorrect handling of escaped characters in patterns
Thanks very much, and apologies for my flawed analysis. It's good to know this will be fixed in bookworm. We're not going to be able to upgrade immediately so it would be nice if it could be fixed in bullseye, but I understand if that isn't the decision.
Bug#1037063: libxml-libxml-perl: Seemingly incorrect handling of escaped characters in patterns
Package: libxml-libxml-perl
Version: 2.0134+dfsg-2+b1
Severity: normal
Dear Maintainer,
I use XML::LibXML::Reader to work with files that validate against the Library
of Congress's MARCXML Schema, available here:
https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd
That schema includes a pattern:
[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
or, with the XML escaping processed:
[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
That regex requires a single character, any one of a long list of allowable
characters. Note how three of the characters require escaping because they
would have meaning in the regex itself: the two square brackets [ and ], and
the backslash \.
An online XML Schema validator that I found with a quick search:
https://www.liquid-technologies.com/online-xsd-validator
shows that those three characters are valid. The problem is that
XML::LibXML::Reader seems to believe that they are not.
I wrote a simple test script, validate.pl:
---
#!/usr/bin/perl
use strict;
use warnings;
use File::Slurp;
use XML::LibXML::Reader;
my ($xml_path, $xsd_path) = @ARGV;
my %parameters = (
'location'=>$xml_path,
'Schema'=>XML::LibXML::Schema->new(string=>scalar(read_file($xsd_path))),
);
my $reader = XML::LibXML::Reader->new(%parameters);
while($reader->read())
{}
print "Finished reading; document must be valid.\n";
---
Along with a basic XML Schema file, test.xsd:
---
http://www.w3.org/2001/XMLSchema";>
---
and a VERY basic XML file, test.xml:
---
---
Running:
$ perl validate.pl test.xml test.xsd
results in:
test.xml:1: Schemas validity error : Element 'root', attribute 'code': [facet
'pattern'] The value '[' is not accepted by the pattern
'[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}'.
I believe that value in fact should match that pattern. The online schema
validator from earlier validates this pair of files. If you replace the data
in the "code" attribute with any of the other characters, validation passes.
It only fails for the three characters that are escaped.
-- System Information:
Debian Release: 11.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libxml-libxml-perl depends on:
ii libc6 2.31-13+deb11u6
ii libxml-namespacesupport-perl 1.12-1.1
ii libxml-sax-perl 1.02+dfsg-1
ii libxml2 2.9.10+dfsg-6.7+deb11u4
ii perl 5.32.1-4+deb11u2
ii perl-base [perlapi-5.32.0]5.32.1-4+deb11u2
libxml-libxml-perl recommends no packages.
libxml-libxml-perl suggests no packages.
-- no debconf information
Bug#1034770: mariadb-server-10.5: Fix for MDEV-29988 (part of 10.5.19) needs to be in stable
Package: mariadb-server-10.5 Version: 1:10.5.18-0+deb11u1 Severity: important X-Debbugs-Cc: x...@charbonnet.com, t...@security.debian.org Dear maintainer, The update in bullseye from 10.5.15 to 10.5.18 on December 4, 2022 contained a major performance problem for some workloads. It causes my DNS server running PowerDNS with a MariaDB backend to run out of memory. This was reported in Debian Bug 1027337: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027337 and fixed by putting 10.5.19 into unstable. However, I (and presumably others?) run stable for my DNS servers, and I'm still stuck on 10.5.15. If anything could be done I would appreciate it. Thanks. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.5 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii galera-4 26.4.11-0+deb11u1 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u5 ii libdbi-perl 1.643-3+b1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.1 1.1.1n-0+deb11u4 ii libstdc++610.2.1-6 ii lsb-base 11.1.0 ii lsof 4.93.2+dfsg-1.1 ii mariadb-client-10.5 1:10.5.18-0+deb11u1 ii mariadb-common1:10.5.18-0+deb11u1 ii mariadb-server-core-10.5 1:10.5.18-0+deb11u1 ii passwd1:4.8.1-1 ii perl 5.32.1-4+deb11u2 ii procps2:3.3.17-5 ii psmisc23.4-2 ii rsync 3.2.3-4+deb11u1 ii socat 1.7.4.1-3 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1.1 Versions of packages mariadb-server-10.5 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 pn mariadb-test pn netcat-openbsd -- debconf-show failed
Bug#1027337: [debian-mysql] Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18
Faustin, Thanks for looking into this, and for your work packaging MariaDB for Debian. It looks to me like https://jira.mariadb.org/browse/MDEV-29988 is very likely to be the issue we're seeing. Fortunately (if I'm interpreting upstream's JIRA correctly), it looks like a fix exists and will be included in 10.5.19. From their release history, 10.5.19 can be expected in early February. Probably what I will do is downgrade all machines to 10.5.15 and look forward to the Debian package of 10.5.19, which hopefully will not be long after the upstream release.
Bug#1027337: "Starting cleanup"
Every few seconds (at least in my configuration), PDNS runs database queries to see which domains need refreshing. After running for a while with this problem, I can "catch" those queries (at least one of them) with SHOW PROCESSLIST. Excerpt: | 117 | pdns | localhost | pdns | Execute |0 | Starting cleanup | SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records WHERE disabled=0 and type=? and name=? |0.000 | It seems to me that the longer this problem has been going on, the longer this query takes, at least the "starting cleanup" phase of it. I think that's why CPU usage climbs: the longer it goes, the longer this query takes and the more CPU is used to execute it. Caught a different one just now, also in phase "starting cleanup": | 128 | pdns | localhost | pdns | Execute |0 | Starting cleanup | SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records WHERE disabled=0 and name=? and domain_id=? |0.000 | Yes, I can regularly "catch" many queries and they're always in state "starting cleanup". I went over to the machine that is not having this problem (because it's still on 10.5.15) and was able to catch one such query in "starting cleanup", and another in "commit". But it took maybe 25x more attempts to catch such a query than on the one with the problem. The queries on the "good" box finish very quickly, and they're slow on the "bad" box.
Bug#1027337: Update 2
At the 96 hour mark it hit 2.5GB, 64.6%. I reverted the seven MariaDB packages back to 10.5.15, and the problem has disappeared. mariadbd is holding steady at 135MB, 3.4%. I'm happy to help participate in figuring out what's going wrong.
Bug#1027337: Update
Some memory statistics. Uptime, resident memory size, and % of memory in the system for mariadbd: 30 hours -- 1.0g -- 26.7% 36 hours -- 1.2g -- 30.3% 54 hours -- 1.6g -- 41.5% Looks like a pretty linear progression of ~33MB/hour being leaked. This is on a system that previously had 512MB of total RAM. Now with 4GB it appears it'll be able to stay up about 5 days total. There were no configuration changes other than upgrading the packages.
Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18
Package: mariadb-server-10.5 Version: 1:10.5.18-0+deb11u1 Severity: important Dear Maintainer, I run a pair of nameservers, and after a recent round of minor software updates (see below for the complete list), mariadbd was OOM'd on both machines. These machines are minimal VMs: one has 512MB RAM, the other 1GB RAM. They've been running various versions of Debian flawlessly for many years. I temporarily upgraded the hardware to 4GB RAM on both in order to remove some urgency from the situation. It does appear that mariadbd's memory consumption is far higher than it should be, and slowly growing. There isn't too much being demanded of this database. Its only client is PowerDNS which runs locally. PowerDNS was not changed in this recent update. Please let me know what additional information I can provide. Thank you! Packages updated when the problem began: base-files:amd64 from 11.1+deb11u5 to 11.1+deb11u6 nftables:amd64 from 0.9.8-3.1 to 0.9.8-3.1+deb11u1 libnftables1:amd64 from 0.9.8-3.1 to 0.9.8-3.1+deb11u1 mariadb-common:all from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 libmariadb3:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-client-core-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-client-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-server-core-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-server-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 libtasn1-6:amd64 from 4.16.0-2 to 4.16.0-2+deb11u1 nano:amd64 from 5.4-2+deb11u1 to 5.4-2+deb11u2 distro-info-data:all from 0.51+deb11u2 to 0.51+deb11u3 grub2-common:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 grub-pc:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 grub-pc-bin:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 grub-common:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 libksba8:amd64 from 1.5.0-3+deb11u1 to 1.5.0-3+deb11u2 linux-image-amd64:amd64 from 5.10.149-2 to 5.10.158-2 linux-libc-dev:amd64 from 5.10.149-2 to 5.10.158-2 mariadb-server:all from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.5 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii galera-4 26.4.11-0+deb11u1 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u5 ii libdbi-perl 1.643-3+b1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.1 1.1.1n-0+deb11u3 ii libstdc++610.2.1-6 ii lsb-base 11.1.0 ii lsof 4.93.2+dfsg-1.1 ii mariadb-client-10.5 1:10.5.18-0+deb11u1 ii mariadb-common1:10.5.18-0+deb11u1 ii mariadb-server-core-10.5 1:10.5.18-0+deb11u1 ii passwd1:4.8.1-1 ii perl 5.32.1-4+deb11u2 ii procps2:3.3.17-5 ii psmisc23.4-2 ii rsync 3.2.3-4+deb11u1 ii socat 1.7.4.1-3 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1.1 Versions of packages mariadb-server-10.5 suggests: ii mailutils [mailx] 1:3.10-3+b1 pn mariadb-test pn netcat-openbsd -- debconf information excluded
Bug#1013351: apticron: Ability to put the Debian version (eg, bullseye, or 11.3) in CUSTOM_SUBJECT
Package: apticron Version: 1.2.5 Severity: wishlist Dear Maintainer, It would be really handy to be able to indicate the specific Debian version (such as "bullseye" or "11.3") in the subject line of apticron emails. Currently there's DISTRIB_ID but it only says "Debian". Could that be updated to say "Debian 11.3" or "Debian bullseye"? Or perhaps a new variable could contain the more specific information? Thank you! -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-15-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apticron depends on: ii apt 2.2.4 ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 ii bzip2 1.0.8-4 ii cron [cron-daemon] 3.0pl1-137 ii dpkg1.20.10 ii ucf 3.0043 Versions of packages apticron recommends: ii apt-listchanges 3.24 ii gpg 2.2.27-2+deb11u1 ii iproute2 5.10.0-4 apticron suggests no packages. -- no debconf information
Bug#1012570: libintl-xs-perl: gettext_xs never used
Package: libintl-xs-perl Version: 1.26-3 Severity: normal Dear Maintainer, I am migrating some systems from stretch to bullseye. These systems use Locale::TextDomain (part of libintl-perl) to do some translations. On bullseye I was getting some wrong responses, and the difference turned out to be that stretch is using the XS version but bullseye is not. I determined this by modifying Locale::Messages to warn about the status of the $no_xs variable. I note that the file gettext_xs.pm was removed for all architectures except mips between buster and bullseye. I copied /usr/lib/x86_64-linux-gnu/perl5/5.24/Locale/gettext_xs.pm from a stretch system to /usr/lib/x86_64-linux-gnu/perl5/5.32/Locale/gettext_xs.pm on bullseye, and now the XS version is being loaded successfully and I'm getting the right answers. Am I missing something in how libintl-xs-perl is supposed to be used? Thanks! *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-14-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libintl-xs-perl depends on: ii libc6 2.31-13+deb11u3 ii libintl-perl1.26-3 ii perl5.32.1-4+deb11u2 ii perl-base [perlapi-5.32.1] 5.32.1-4+deb11u2 libintl-xs-perl recommends no packages. libintl-xs-perl suggests no packages. -- no debconf information
Bug#1001467: mariadb-10.5: Backport MariaDB 10.5.13 fixes? (Particularly MDEV-26712)
Source: mariadb-10.5 Version: 10.5.12-0+deb11u1 Severity: important Dear Maintainer, I've been investigating an issue where my MariaDB server ends up running away with the RAM on the machine. I believe it may be caused by MDEV-26712 [1], which is a memory leak bug. According to the MariaDB 10.5.13 release notes [2], this was fixed in that release. I see a number of other fixes as well. Are there any plans to backport these fixes to Bullseye, or to move Bullseye to 10.5.13? I should mention that I'm not 100% sure that this is the fix to my problem: apparently this problem applies to earlier versions as well, and I don't have this issue on earlier versions. So it may be something else. Regardless of my particular situation, the MariaDB in Bullseye does contain this bug that can consume any amount of RAM. [1] https://jira.mariadb.org/browse/MDEV-26712 [2] https://mariadb.com/kb/en/mariadb-10513-release-notes/ -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#991972: More information
[Sorry, Tomas, I just realized that earlier I replied only to you rather than to the whole list.] There is some Debian blessing of backports.org. When visiting the Debian webserver over http and asking for www.backports.org, the Debian webserver redirects the visitor to https://backports.debian.org/. It doesn't seem that there should be a difference in behavior between http://www.backports.org/ and https://www.backports.org/, but as it is, one works perfectly and the other fails spectacularly. I see the options as: a) Let backports.org die, which is mostly what you suggest. Shouldn't the Debian webserver should have any backports.org configuration removed from it? I believe would mean that visitors to http://www.backports.org/ will end up getting the Debian homepage. The owner of backports.org should be contacted so the domain could be removed, which I'd be glad to attempt. b) Configure the Debian webserver to acquire a certificate from Let's Encrypt for www.backports.org and configure it to redirect visitors to backports.debian.org just as the http:// version does. c) Leave things as they are, where http:// works and https:// doesn't. I just thought this was a weird situation. If you like it the way it is, it's fine by me. Thanks for your work on the Debian website! -Xan
Bug#991972: More information
Sorry, I should have checked this on more than one browser before reporting. For some reason my ancient Firefox profile, when I browse to "backports.org", redirects to https://www.backports.org/. Perhaps this was a cached permanent redirect, or something to do with HSTS. On a naive profile (with seemingly any browser), browsing to "backports.org" fails, because backports.org has no A record. Not terribly friendly but not a problem. It sounds like your browser has some memory that points backports.org to backports.debian.org. A naive browser has no way to return anything for https://backports.org/ or http://backports.org/. www.backports.org does have a CNAME record: it points to backports.debian.org, which seems to have the same IP address as debian.org. Browsing to http://www.backports.org/ is successful: the Debian webserver redirects the request to https://backports.debian.org/, and when accessed via that name, the Debian webserver correctly serves the backports page. However, when you browse to https://www.backports.org/ (note the secure protocol), that's when it breaks. The Debian webserver defaults to serving the Debian homepage, complete with the TLS certificate for debian.org. This causes a nasty security error in the browser, and if bypassed, results in the Debian homepage loading at https://www.backports.org/ rather than the Backports page. The only remaining mystery is why my Firefox profile is handling "backports.org" the way it is. I'm trying to figure out how to diagnose that, but it doesn't seem like there's much visibility to that kind of thing. It could be something that affects everybody who visited backports.org during a particular timeframe.
Bug#991972: backports.org invalid certificate
Package: www.debian.org Some muscle memory from a long time ago kicked in, and I browsed to backports.org instead of to backports.debian.org. backports.org now seems to serve the Debian homepage, and in the process triggers the browser's invalid certificate error, because the certificate is for www.debian.org. It seems to me that backports.org should redirect to backports.debian.org. I'm not sure why the Debian homepage would greet somebody visiting backports.org, but if that's desired, it should redirect to www.debian.org rather than simply serve its content. In either case backports.org should have its own proper certificate. Or backports.org could go away.
Bug#969091: pdns-backend-mysql: Queries calling stored procedures broken with recent MariaDB/MySQL
Hi Chris, On the pdns mailing list, it's been requested I file an issue in the GitHub repository. I've done so: https://github.com/PowerDNS/pdns/issues/9421 It includes detailed steps to reproduce. It really just boils down to setting one of the queries to use a stored procedure, eg: gmysql-basic-query=CALL basic_query(?, ?) Do the Debian tests include stored procedures? Or just regular SQL queries? -Xan
Bug#969091: pdns-backend-mysql: Queries calling stored procedures broken with recent MariaDB/MySQL
Package: pdns-backend-mysql
Version: 4.3.0-4+b3
Severity: important
Tags: upstream
X-Debbugs-Cc: x...@charbonnet.com
Dear Maintainer,
PowerDNS supports using stored procedures for its backend MySQL queries.
However, it seems
that when the database is MariaDB >= 10.2 (or MySQL >= 5.7), stored procedures
fail to work.
I have tested this on Stretch, using three different PowerDNS versions: 4.0.3
(from Stretch),
4.1.6 (from Buster), and 4.3.0 (from Bullseye), all compiled on Stretch. They
all have the
same behavior: on MariaDB 10.1, stored procedures work great. On MariaDB 10.2,
calls to
procedures which return any rows give the error "Could not bind parameters to
mysql
statement". The various versions of MariaDB came from the MariaDB Debian
repositories.
I have also tried this on a clean Bullseye test system, using the versions of
PowerDNS and
MariaDB which are native to Bullseye. Same problem. This is the system where
I'm running
reportbug.
I believe this other user on the pdns mailing list encountered this problem:
https://mailman.powerdns.com/pipermail/pdns-users/2020-July/026762.html
My reply failed to actually be a reply, but I also chimed in on the list:
https://mailman.powerdns.com/pipermail/pdns-users/2020-August/026810.html
The relevant code appears to be the following section. Unfortunately I don't
know enough
about using MySQL from C++ to be able to tell what to do differently. This is
where the
"Could not bind parameters" error is coming from.
#if MYSQL_VERSION_ID >= 50500
if (d_residx >= d_resnum) {
mysql_stmt_free_result(d_stmt);
while(!mysql_stmt_next_result(d_stmt)) {
if ((err = mysql_stmt_store_result(d_stmt))) {
string error(mysql_stmt_error(d_stmt));
releaseStatement();
throw SSqlException("Could not store mysql statement while
processing additional sets: " + d_query + string(": ") + error);
}
d_resnum = mysql_stmt_num_rows(d_stmt);
// XXX: For some reason mysql_stmt_result_metadata returns
NULL here, so we cannot
// ensure row field count matches first result set.
if (d_resnum > 0) { // ignore empty result set
if (d_res_bind != nullptr && (err =
mysql_stmt_bind_result(d_stmt, d_res_bind))) {
string error(mysql_stmt_error(d_stmt));
releaseStatement();
throw SSqlException("Could not bind parameters to mysql
statement: " + d_query + string(": ") + error);
}
d_residx = 0;
break;
}
mysql_stmt_free_result(d_stmt);
}
}
#endif
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pdns-backend-mysql depends on:
ii libc62.31-2
ii libgcc-s110.1.0-6
ii libmariadb3 1:10.3.23-1
ii libstdc++6 10.1.0-6
ii pdns-server 4.3.0-4+b3
pdns-backend-mysql recommends no packages.
Versions of packages pdns-backend-mysql suggests:
pn default-mysql-server
-- no debconf information
Bug#924956: qt3d-opensource-src: Fractional HiDPI scaling causes serious artifacts in some QT applications
I'm very sorry for the error. I am running the latest Buster for everything. The problem I'm experiencing sounds an awful lot like the description of that bug, so I assumed the fix hadn't been implemented in Debian. If it has, then it must be a different problem. (Or the fix isn't complete, or something.) I've just confirmed that when I set the scaling to 1, the problem goes away. When I set the scaling to my preferred setting, 1.1, the problem is rampant.
Bug#924956: Image example
https://imgur.com/download/Diwa8qz
Bug#924956: qt3d-opensource-src: Fractional HiDPI scaling causes serious artifacts in some QT applications
Source: qt3d-opensource-src Severity: important Tags: newcomer Dear Maintainer, QT has had a bug which caused major artifacts in QT applications, for example Kate, Kwrite, Konsole, and probably many others. It only is an issue when non-integer scaling factors for HiDPI are used. At least for me, this makes Kate very difficult to use. The bug was fixed on this page: https://bugreports.qt.io/browse/QTBUG-66036 Comment #6 contains the fix, which is quite small. You may have to click the "X older comments" link to get this comment to appear. It was too late to make it into QT 5.11, sadly, but there is (or was?) talk of cherry-picking the patch into 5.11: https://phabricator.kde.org/T9244 If this patch could make it into Buster's QT, that would be fantastic. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#889798: (Security) bugs in pdns in stretch
I installed pdns-server_4.0.3-1+deb9u3_amd64.deb and pdns-backend-mysql_4.0.3-1+deb9u3_amd64.deb and everything worked perfectly. Thanks!
Bug#889798: pdns-backend-mysql: Queries calling stored procedures break PowerDNS in weird ways
An update: versions 4.0.6 and 4.1.5 were released a few days ago. 4.1.5 does contain this fix, so that's the good news. If 4.1.5 makes buster (which I'm assuming it would), the fix would automatically be in buster and later versions of Debian. Unfortunately the fix seems to NOT have been included in 4.0.6. I don't know why that is the case. I'm guessing that means it won't make sense to apply the patch to the Debian version in stretch. For what it's worth, I've been running such a patched version with no trouble since February, and I suppose I'll just keep doing that until buster. Thanks for your work on PowerDNS in Debian!
Bug#889798: pdns-backend-mysql: Queries calling stored procedures break PowerDNS in weird ways
That's more than fair. I can keep an eye on when this code gets into an actual release, and some time after that, comment here that things are looking good (or that they're not). The risk I was attempting to minimize was the behavioral change. If people relied on the current behavior, then applying this fix to stable would be problematic. I'm arguing that that concern doesn't apply. As far as the risk of this fix introducing some other bug or otherwise having adverse affects, I'll defer entirely to your judgment. Seeing how this plays out upstream before making any changes to stable makes perfect sense.
Bug#889798: pdns-backend-mysql: Queries calling stored procedures break PowerDNS in weird ways
Package: pdns-backend-mysql Version: 4.0.3-1+deb9u2 Severity: important Tags: patch Dear Maintainer, PowerDNS versions 4.x (the versions in Jessie, Stretch, Buster, and Sid) fails to handle stored procedures. When a stored procedure is used as one of the PowerDNS queries, it works the first time, but subsequent queries return really weird results. It appears that these results are from some kind of cache, but they're simply broken. The troubleshooting described at this link mirrors my diagnostic process: https://github.com/PowerDNS/pdns/issues/6115 The fix: https://github.com/PowerDNS/pdns/pull/6134/files was merged 5 days ago into upstream. There has not yet been an upstream release containing this fix. Because it has been accepted upstream, I don't believe anything special needs to be done for Buster or Sid, other than keeping up with upstream. I'm asking you to consider updating the version in Stretch (and possibly the one in Jessie). While I don't believe this is a security issue, PowerDNS in these distributions is plainly broken when used with stored procedures. Nobody will be inconvenienced by this change in behavior, and it will allow PowerDNS to work as documented and intended. I successfully merged this patch into the Debian version of PowerDNS from Stretch for my own local use. It worked great. It would be really nice if the official package could include this fix. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (1000, 'stable'), (900, 'stable'), (750, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core) 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) Versions of packages pdns-backend-mysql depends on: ii dbconfig-common2.0.8 ii dbconfig-mysql 2.0.8 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u1 ii libgcc11:6.3.0-18 ii libmariadbclient18 10.1.26-0+deb9u1 ii libstdc++6 6.3.0-18 ii pdns-server4.0.3-1+deb9u2 ii ucf3.0036 ii zlib1g 1:1.2.8.dfsg-5 pdns-backend-mysql recommends no packages. Versions of packages pdns-backend-mysql suggests: pn default-mysql-server -- debconf information excluded
Bug#733820: pound: Add libgoogle-perftools-dev to build-dependencies
Package: pound Version: 2.6-2 Severity: wishlist Is it possible to add libgoogle-perftools-dev to the build-dependencies for pound? This was briefly the case back in 2008, but was backed out because libgoogle-perftools-dev didn't look like it would be in testing. It's certainly there now, and has even been in stable for quite a long time (at least since Squeeze). Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#419209: lvm2: Hangs during snapshot creation
Package: lvm2 Version: 2.02.95-4 Followup-For: Bug #419209 Hello, It looks like this bug still exists in wheezy. I use LVM to keep snapshots of the database partitions on my backup servers. Every half hour, a new snapshot is created (and, usually, an old one destroyed). This worked perfectly in squeeze. A few days ago, I configured a new backup server with a fresh install of wheezy, and I'm seeing what I believe are the symptoms of this bug. Sometimes the snapshot creation goes just fine, but sometimes lvcreate hangs, blocked for I/O forever. I have to use sysrq to force the system to reboot. There's no RAID involved. (The system is on an md RAID1 mirror, but the LVM volume lives on /dev/sdb1, straight-up.) I've tried ext4 and ext3. I've tried creating the snapshot with the partition mounted and with the partition unmounted. I've tried a different hard drive. Whatever I try, lvcreate hangs very regularly. I can do whatever experiments on this system might be helpful. Please let me know how I can help to track this down. Thanks! -Xan -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lvm2 depends on: ii dmsetup 2:1.02.74-4 ii initscripts 2.88dsf-34 ii libc6 2.13-38 ii libdevmapper-event1.02.1 2:1.02.74-4 ii libdevmapper1.02.12:1.02.74-4 ii libreadline5 5.2+dfsg-1 ii libudev0 175-7 ii lsb-base 4.1+Debian8 lvm2 recommends no packages. lvm2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#447186: uhci_hcd unload hangs on suspend
Package: linux-image-2.6.18-5-686 Version: 2.6.18.dfsg.1-13etch4 Up until this latest version of 2.6.18-5, on my Inspiron 8600 I have been able to right-click on the "kpowersave" icon in the KDE system tray and select "Suspend to Disk". It would very quickly prepare the system to suspend, and then the screen would switch to text mode and count the percentages as it wrote the memory to the hard drive. Now, the preparation hangs when it tries to unload module uhci_hcd. The keyboard and mouse quit responding, and I have to power down. I'm working around this by booting to 2.6.18-4, where it works fine. It also worked on the earlier version of 2.6.18-5, but that was blasted by the update. This is pretty much a standard, non-tricked-out, etch install. I have just a few things from debian-multimedia.org, plus Opera, all installed via dpkg. Everything else is plain etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
