Bug#695145:
reported upstream. Patch there as well https://sourceforge.net/tracker/?func=detail&aid=3596229&group_id=269812&atid=1147701 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691309: /var/lib/munin-async owned by root while munin-asyncd started as user munin-async
Package: munin-async Version: 2.0.6-1~bpo60+1 Severity: important Tags: patch As the munin-asyncd process needs to write to /var/lib/munin-async this package should make this directory owned by the munin-async user when it installs it. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.5.2-linode45 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin-async depends on: ii adduser3.112+nmu2add and remove users and groups ii munin-common 2.0.6-1~bpo60+1 network-wide graphing framework (c ii munin-node 2.0.6-1~bpo60+1 network-wide graphing framework (n ii perl 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii perl-modules 5.10.1-17squeeze3 Core Perl modules munin-async recommends no packages. munin-async 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#691390: munin-async init script runs before munin-node and dies
Package: munin-async Version: 2.0.6-1~bpo60+1 Severity: important Both munin-node and munin-async start at S17 on runlevels 2 3 4 5. munin-async however requires that munin-node is running otherwise it terminates. Because alphabetically munin-async < munin-node this always fails on startup. Please make munin-async look for the munin-node network connection or just start it later. Cheers -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.5.2-linode45 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin-async depends on: ii adduser3.112+nmu2add and remove users and groups ii munin-common 2.0.6-1~bpo60+1 network-wide graphing framework (c ii munin-node 2.0.6-1~bpo60+1 network-wide graphing framework (n ii perl 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii perl-modules 5.10.1-17squeeze3 Core Perl modules munin-async recommends no packages. munin-async 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#691390:
patch here: https://github.com/grooverdan/munin-debian/commit/8e537fcc99632de38f3d9fe5ec5dad3d4fc26250 (with other munin patches) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691309:
patch here: https://github.com/grooverdan/munin-debian/commit/ed145ce0067ddc40911aa0077f52ae456d50438d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691758: munin-async logrotate directory specifies /var/lib/munin/spool when /var/lib/munin-async is used
Package: munin-async patch: https://github.com/grooverdan/munin-debian/commit/74919f02b17eed908cdd362b60e71a00b9ea5041 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691759: munin-async runs daemon in /usr/share/munin/munin-asyncd rather than /usr/sbin
Package: munin-async patch: https://github.com/grooverdan/munin-debian/commit/155116a7c9c716c58eadb45ee490d82eb6a6c6c9 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681803: documentation
I've reworked the article a little to account for fixes (including some of my pending ones) and improvments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681803: documentation
patch: https://github.com/grooverdan/munin-debian/commit/162dd395cb75889d57b0dc36c114cc3dccfe1243 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691761: mysql_ plugin need libcache-cache-perl
package: munin-plugins-core patch: https://github.com/grooverdan/munin-debian/commit/598a1ebe07ec46fadb3da741e7f4b0c5e23949c7 sample from munin.log without dependancy installed: -- -- Daniel Black, Engineer @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676798:
patch: https://github.com/grooverdan/munin-debian/commit/ff90b8f3be96128afc5d3a45f60131e61aafb1a4 doesn't disable the cidr as recommended previously however. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691758:
munin-async files are like munin-daemon.smart_sdc.1351296000.86400 so logrotate
should be *0 rather than *.0
https://github.com/grooverdan/munin-debian/commit/156076fe0c30dccbf9d1f12cf06f090e562ba8be
like
https://github.com/grooverdan/munin-debian/blob/fixes/debian/munin-async.logrotate
/var/lib/munin-async/*0 {
daily
missingok
...
--
Daniel Black, Engineer @ Open Query (http://openquery.com)
Remote expertise & maintenance for MySQL/MariaDB server environments.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693184: opendkim-genkey generates g=* which is obsolete and discouraged (rfc6376 C.2)
Package: opendkim Version: 2.0.1+dfsg-1 Severity: normal run opendkim-genkey: look at default.txt. This has a deprecated g=* default._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUS6bO3Gk/xAHIlOOxYVAh+tXqdxkPDqQfXurDryvMlfe3m9Nl9CddAmRPpR/KckalaoE0RhRDL6WyU vxN7MwLA7q1p+bMmctx4OxTaG87EIFkw3Jy0oBCV6hJoy5WY1NGhiko8ZjwAD1YwoFi/4Oqf7p+Yiam9gcnNxhmRTc7TwIDAQAB" ; - DKIM default for example.com >From rfc6376 secionn C.2 (https://tools.ietf.org/html/rfc6376#appendix-C.2) Although the "g=" tag has been deprecated in this version of the DKIM specification (and thus MUST now be ignored), Signers are advised not to include the "g=" tag in key records because some [RFC4871]- compliant Verifiers will be in use for a considerable period to come. -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32.46-xenU (SMP w/2 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 opendkim depends on: ii adduser3.112+nmu2add and remove users and groups ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libldap-2.4-2 2.4.23-7.2OpenLDAP libraries ii liblua5.1-05.1.4-5 Simple, extensible, embeddable pro ii libmilter1.0.1 8.14.3-9.4Sendmail Mail Filter API (Milter) ii libopendkim1 2.0.1+dfsg-1 Library for signing and verifying ii libssl0.9.80.9.8o-4squeeze13 SSL shared libraries ii libunbound21.4.6-1+squeeze2 library implementing DNS resolutio opendkim recommends no packages. opendkim suggests no packages. -- Configuration Files: /etc/opendkim.conf changed [not included] -- 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#500192: patch based of gentoo's
--
Daniel Black
Cloud Central
Scale Your Data Center In The Cloud
Switch: 1300 144 007
Fax: 02 6173 7339
Email: dan...@cloudcentral.com.au
--- /etc/init.d/ssh.orig 2010-02-11 18:27:46.0 +1100
+++ /etc/init.d/ssh 2010-02-11 18:32:16.0 +1100
@@ -57,6 +57,17 @@
fi
}
+check_ssh_host_key() {
+if [ ! -e /etc/ssh/ssh_host_key ]; then
+ /usr/bin/ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N '' || exit 1
+fi
+if [ ! -e /etc/ssh/ssh_host_dsa_key ]; then
+ /usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N '' || exit 1
+fi
+if [ ! -e /etc/ssh/ssh_host_rsa_key ]; then
+ /usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N '' || exit 1
+fi
+}
check_privsep_dir() {
# Create the PrivSep empty dir if necessary
if [ ! -d /var/run/sshd ]; then
@@ -75,6 +86,7 @@
case "$1" in
start)
+check_ssh_host_key
check_privsep_dir
check_for_no_start
check_dev_null
Bug#500192: another scipt references + business case
Its also very useful to have this feature when deploying vm images in cloud computing environment or other private standardised and virtualised infrastructure. other distro reference init scripts for reference; http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openssh/files/sshd.rc6?view=markup http://cvs.fedoraproject.org/viewvc/rpms/openssh/F-11/sshd.init?view=markup thanks for your maintainer efforts so far. -- Daniel Black Cloud Central Scale Your Data Center In The Cloud Switch: 1300 144 007 Fax: 02 6173 7339 Email: dan...@cloudcentral.com.au -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557508: libunbound-dev: /usr/lib/libunbound.la references -lldns without a dependency on libldns1
Package: libunbound-dev Version: 1.0.2-1 Severity: normal The libunbound.so library also contains a dynamic section to ldns and there are ldns symbols in the file: readelf -a /usr/lib/libunbound.so |fgrep UND\ ldns 3: 152 FUNCGLOBAL DEFAULT UND ldns_calc_keytag_raw 5: 39 FUNCGLOBAL DEFAULT UND ldns_rdf_free 12: 10 FUNCGLOBAL DEFAULT UND ldns_rr_owner 37: 75 FUNCGLOBAL DEFAULT UND ldns_rdf_size 38: 133 FUNCGLOBAL DEFAULT UND ldns_rr_free 41: 98 FUNCGLOBAL DEFAULT UND ldns_rr_descript 45: 76 FUNCGLOBAL DEFAULT UND ldns_rdf_data 59: 70 FUNCGLOBAL DEFAULT UND ldns_rdf_deep_free 60: 3714 FUNCGLOBAL DEFAULT UND ldns_rr_new_frm_str 64: 67 FUNCGLOBAL DEFAULT UND ldns_rr_rdf 67: 1216 FUNCGLOBAL DEFAULT UND ldns_pkt2buffer_str 69: 52 FUNCGLOBAL DEFAULT UND ldns_buffer2pkt_wire 70: 11 FUNCGLOBAL DEFAULT UND ldns_rr_ttl 74: 43 FUNCGLOBAL DEFAULT UND ldns_dname_new_frm_str 80: 254 FUNCGLOBAL DEFAULT UND ldns_key_buf2rsa_raw 83: 11 FUNCGLOBAL DEFAULT UND ldns_rr_get_class 91: 11 FUNCGLOBAL DEFAULT UND ldns_rr_get_type 99: 40 FUNCGLOBAL DEFAULT UND ldns_lookup_by_id 116: 204 FUNCGLOBAL DEFAULT UND ldns_rr_dnskey_key_size_r 118: 66 FUNCGLOBAL DEFAULT UND ldns_buffer_free 120: 443 FUNCGLOBAL DEFAULT UND ldns_rr_new_frm_fp_l 122: 249 FUNCGLOBAL DEFAULT UND ldns_key_buf2dsa_raw 124: 56 FUNCGLOBAL DEFAULT UND ldns_get_errorstr_by_id 131: 119 FUNCGLOBAL DEFAULT UND ldns_pkt_free 135: 96 OBJECT GLOBAL DEFAULT UND ldns_rcodes 138: 172 FUNCGLOBAL DEFAULT UND ldns_buffer_new 151: 337 FUNCGLOBAL DEFAULT UND ldns_buffer_copy 155: 89 FUNCGLOBAL DEFAULT UND ldns_rr_rdata2buffer_wire 160: 40 OBJECT GLOBAL DEFAULT UND ldns_rr_classes -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-vserver-686 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libunbound-dev depends on: ii libunbound0 1.0.2-1library implementing DNS resolutio libunbound-dev recommends no packages. libunbound-dev 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#557508: libunbound-dev: /usr/lib/libunbound.la references -lldns without a dependency on libldns1
On Monday 23 November 2009 23:32:11 Ondřej Surý wrote: > And what is the problem? > > libunbound1 does depend on libldns1 and none of the exported symbols > from libunbound-dev does need libldns-dev. Ok. at the moment I only have libunbound-dev installed. The ldns hint in the libunbound.la file caused a linker compile error as it can't find libldns when trying to compile against libunbound. As there is no dependency as you've investigated the -lldns shouldn't be in the .la file. I've checked this by manually removing it and at least opendkim compiles and runs ok without it. Thanks for looking closer at the exports than I did. signature.asc Description: This is a digitally signed message part.
Bug#656326: also fix status
As recommended by CoolCold.
Also changed NAME to searchd to make "/etc/init.d/sphinxsearch status" work.
The /proc/{pid}/cmdline is searchd not /usr/bin/search when checking the status.
--
--
Daniel Black, Engineer @ Open Query (http://openquery.com)
Remote expertise & maintenance for MySQL/MariaDB server environments.diff --git a/sphinxsearch-2.0.4/debian/cron.d b/sphinxsearch-2.0.4/debian/cron.d
index d14f324..d545f84 100644
--- a/sphinxsearch-2.0.4/debian/cron.d
+++ b/sphinxsearch-2.0.4/debian/cron.d
@@ -1,9 +1,9 @@
# Rebuild all indexes daily and notify searchd.
-@daily root . /etc/default/sphinxsearch && if [ "$START" = "yes" ] && [ -x /usr/bin/indexer ]; then /usr/bin/indexer --quiet --rotate --all; fi
+@daily sphinxsearch . /etc/default/sphinxsearch && if [ "$START" = "yes" ] && [ -x /usr/bin/indexer ]; then /usr/bin/indexer --quiet --rotate --all; fi
# Example for rotating only specific indexes (usually these would be part of
# a larger combined index).
-# */5 * * * * root [ -x /usr/bin/indexer ] && /usr/bin/indexer --quiet --rotate postdelta threaddelta
+# */5 * * * * sphinxsearch [ -x /usr/bin/indexer ] && /usr/bin/indexer --quiet --rotate postdelta threaddelta
diff --git a/sphinxsearch-2.0.4/debian/init.d b/sphinxsearch-2.0.4/debian/init.d
index e128333..b380b4d 100644
--- a/sphinxsearch-2.0.4/debian/init.d
+++ b/sphinxsearch-2.0.4/debian/init.d
@@ -20,7 +20,7 @@
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/searchd
-NAME=sphinxsearch
+NAME=searchd
DESC=sphinxsearch
test -x $DAEMON || exit 0
@@ -78,7 +78,7 @@ running()
[ ! -f "$PIDFILE" ] && return 1
# Obtain the pid and check it against the binary name
pid=`cat $PIDFILE`
-running_pid $pid $DAEMON || return 1
+running_pid "${pid}" "${NAME}" || return 1
return 0
}
@@ -98,7 +98,7 @@ do_force_stop() {
fi
fi
fi
-rm -f $PIDFILE
+rm -f "${PIDFILE}"
return 0
}
do_start() {
@@ -110,18 +110,18 @@ do_start() {
exit 1
fi
-start-stop-daemon --start --pidfile $PIDFILE --chuid sphinxsearch --exec ${DAEMON}
+start-stop-daemon --start --pidfile "$PIDFILE" --chuid sphinxsearch --exec "${DAEMON}"
}
do_stop() {
-start-stop-daemon --stop --quiet --oknodo --user sphinxsearch --pidfile $PIDFILE \
---exec $DAEMON
+start-stop-daemon --stop --quiet --oknodo --user sphinxsearch --pidfile "${PIDFILE}" \
+--exec "${DAEMON}"
}
case "$1" in
start)
echo -n "Starting $DESC: "
do_start
-[ -n "$STARTDELAY" ] && sleep $STARTDELAY
+[ -n "$STARTDELAY" ] && sleep "${STARTDELAY}"
if running ; then
echo "$NAME."
@@ -146,7 +146,7 @@ case "$1" in
restart|reload|force-reload)
echo -n "Restarting $DESC: "
do_stop
-[ -n "$DODTIME" ] && sleep $DODTIME
+[ -n "$DODTIME" ] && sleep "${DODTIME}"
do_start
echo "$NAME."
;;
Bug#656326: init script and cron.d
Another small improvement is the cron.d should run as sphinxsearch too. For the indexer --rotate in cron to work it needs to send a signal to the searchd process and therefore the indexer needs to be able to read the pid file. In the init script chmod or chown the pid file such that the sphinxsearch user can read this file. Cheers and thanks for packaging this. -- Daniel Black, Engineer @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656326: init script and cron.d
Another small improvement is the cron.d should run as sphinxsearch too. For the indexer --rotate in cron to work it needs to send a signal to the searchd process and therefore the indexer needs to be able to read the pid file. In the init script chmod or chown the pid file such that the sphinxsearch user can read this file. Cheers and thanks for packaging this. -- Daniel Black, Engineer @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659183: postfix selinux errors
Package: selinux-policy-default
Version: 2:0.2.20100524-7+squeeze1
Severity: important
Similar to bug 599053 which is archived:
New install:
Error 1: sendmail...
Cannot run (postfix) sendmail under selinux
$ sudo ls -ldaZ /usr/sbin/postdrop /var/spool/postfix/maildrop
-r-xr-sr-x. 1 rootpostdrop system_u:object_r:bin_t:s0 14384 May
4 2011 /usr/sbin/postdrop
drwx-wx--T. 2 postfix postdrop unconfined_u:object_r:var_spool_t:s0 6 Feb
8 16:16 /var/spool/postfix/maildrop
$ /usr/sbin/sendmail -f t...@somewhere.com nowh...@elsewhere.com
postdrop: warning: mail_queue_enter: create file maildrop/113920.21397:
Permission denied
^C
type=AVC msg=audit(1328737132.109:486): avc: denied { write } for pid=21397
comm="postdrop" name="maildrop" dev=xvdc ino=273140255
scontext=unconfined_u:unconfined_r:user_mail_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:var_spool_t:s0 tclass=dir
Error 2: mailq
Running postfix mailq returns error.
$ mailq
postqueue: fatal: Connect to the Postfix showq service: Permission denied
type=AVC msg=audit(1328737230.494:487): avc: denied { write } for pid=21411
comm="postqueue" name="showq" dev=xvdc ino=387746
scontext=unconfined_u:unconfined_r:user_mail_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:var_spool_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1328737230.494:487): arch=c03e syscall=42 success=no
exit=-13 a0=4 a1=7fff59526a90 a2=6e a3=8 items=0 ppid=13532 pid=21411
auid=4294967295 uid=1003 gid=1004 euid=1003 suid=1003 fsuid=1003 egid=111
sgid=111 fsgid=111 tty=pts1 ses=4294967295 comm="postqueue"
exe="/usr/sbin/postqueue"
subj=unconfined_u:unconfined_r:user_mail_t:s0-s0:c0.c1023 key=(null)
$ sudo ls -ladZ /var/spool/postfix/public/showq
srw-rw-rw-. 1 postfix postdrop unconfined_u:object_r:var_spool_t:s0 0 Feb 8
15:06 /var/spool/postfix/public/showq
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656326: reopen 656326 - cron.d permissions as non-root for running indexer
reopen 656326
No cron changes or permission changes on the pid occurred. I've attached the
diff in the attached patch. I also enhanced the variable escaping.
--
--
Daniel Black, Engineer @ Open Query (http://openquery.com)
Remote expertise & maintenance for MySQL/MariaDB server environments.--- init.d 2012-04-20 12:29:32.0 +1000
+++ init.d.new 2012-04-21 12:50:10.677176244 +1000
@@ -78,7 +78,7 @@
[ ! -f "$PIDFILE" ] && return 1
# Obtain the pid and check it against the binary name
pid=`cat $PIDFILE`
-running_pid $pid $DAEMON || return 1
+running_pid "${pid}" "${DAEMON}" || return 1
return 0
}
@@ -98,7 +98,7 @@
fi
fi
fi
-rm -f $PIDFILE
+rm -f "${PIDFILE}"
return 0
}
do_start() {
@@ -110,18 +110,20 @@
exit 1
fi
-start-stop-daemon --start --pidfile $PIDFILE --chuid sphinxsearch --exec ${DAEMON}
+start-stop-daemon --start --pidfile "$PIDFILE" --chuid sphinxsearch --exec "${DAEMON}"
+chgrp sphinxsearch "$PIDFILE"
+chmod g+r "$PIDFILE"
}
do_stop() {
-start-stop-daemon --stop --quiet --oknodo --user sphinxsearch --pidfile $PIDFILE \
---exec $DAEMON
+start-stop-daemon --stop --quiet --oknodo --user sphinxsearch --pidfile "${PIDFILE}" \
+--exec "${DAEMON}"
}
case "$1" in
start)
echo -n "Starting $DESC: "
do_start
-[ -n "$STARTDELAY" ] && sleep $STARTDELAY
+[ -n "$STARTDELAY" ] && sleep "${STARTDELAY}"
if running ; then
echo "$NAME."
@@ -146,7 +148,7 @@
restart|reload|force-reload)
echo -n "Restarting $DESC: "
do_stop
-[ -n "$DODTIME" ] && sleep $DODTIME
+[ -n "$DODTIME" ] && sleep "${DODTIME}"
do_start
echo "$NAME."
;;
--- cron.d 2011-04-09 18:12:43.0 +1000
+++ cron.d.new 2012-04-21 12:52:40.859381472 +1000
@@ -1,6 +1,6 @@
# Rebuild all indexes daily and notify searchd.
-@daily root . /etc/default/sphinxsearch && if [ "$START" = "yes" ] && [ -x /usr/bin/indexer ]; then /usr/bin/indexer --quiet --rotate --all; fi
+@daily sphinxsearch . /etc/default/sphinxsearch && if [ "$START" = "yes" ] && [ -x /usr/bin/indexer ]; then /usr/bin/indexer --quiet --rotate --all; fi
# Example for rotating only specific indexes (usually these would be part of
# a larger combined index).
Bug#647346: usb-modeswitch-data: version bump to 20111023 available http://www.draisberghof.de/usb_modeswitch/#download
Package: usb-modeswitch-data Version: 20111023 Severity: normal This version bump contains a number of additional 3G modems that don't have switch mode configurations. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652319: selinux-policy-default: avc denial errors /lib/udev/fstab_import on /etc/fstab
Package: selinux-policy-default
Version: 2:0.2.20100524-7+squeeze1
Severity: low
On bootup I'm getting the following errors:
Dec 15 20:25:43 tx-web01 kernel: [1419609.818930] type=1400
audit(1323998741.657:3): avc: denied { read } for
pid=245 comm="fstab_import" name="fstab" dev=xvda ino=5548807
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file
Dec 15 20:25:43 tx-web01 kernel: [1419609.818966] type=1400
audit(1323998741.657:4): avc: denied { open } for
pid=245 comm="fstab_import" name="fstab" dev=xvda ino=5548807
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file
Dec 15 20:25:43 tx-web01 kernel: [1419609.819013] type=1400
audit(1323998741.657:5): avc: denied { getattr } for
pid=245 comm="fstab_import" path="/etc/fstab" dev=xvda ino=5548807
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=file
ls -laZ /lib/udev/fstab_import /bin/mount
-rwsr-xr-x. 1 root root system_u:object_r:mount_exec_t:s0 78616 Jan 25 2011
/bin/mount
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s022528 Dec 12 2010
/lib/udev/fstab_import
-rw-r--r--. 1 root root system_u:object_r:file_t:s0 466 Dec 15 20:25
/etc/fstab
# restorecon /etc/fstab
# ls -laZ /etc/fstab
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 466 Dec 15 20:25 /etc/fstab
After a reboot it appears the label of fstab is reverted. I haven't edited
/etc/fstab between these two events.
$ ls -laZ /etc/fstab
-rw-r--r--. 1 root root system_u:object_r:file_t:s0 466 Dec 15 21:21 /etc/fstab
$ sudo restorecon /etc/fstab
$ ls -laZ /etc/fstab
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 466 Dec 15 21:21 /etc/fstab
-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages selinux-policy-default depends on:
ii libpam-modules1.1.1-6.1+squeeze1 Pluggable Authentication Modules f
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii libsepol1 2.0.41-1 SELinux library for manipulating b
ii policycoreutils 2.0.82-3 SELinux core policy utilities
ii python2.6.6-3+squeeze6 interactive high-level object-orie
Versions of packages selinux-policy-default recommends:
ii checkpolicy 2.0.22-1SELinux policy compiler
ii setools 3.3.6.ds-7.2+b1 tools for Security Enhanced Linux
Versions of packages selinux-policy-default suggests:
pn logcheck (no description available)
pn syslog-summary (no description available)
-- 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#403166: works fine as nobody + initscript flaws
Package: postfix-policyd Priority: optional Section: mail Installed-Size: 328 Maintainer: OndÅej Surý <[EMAIL PROTECTED]> Architecture: i386 Version: 1.80-2.2 /etc/postfix-policyd.conf by default autobackgrounds and sets a PID file so heres a patch against the init script. --- /tmp/policyd/etc/init.d/postfix-policyd 2007-08-04 19:03:55.0 + +++ /etc/init.d/postfix-policyd 2007-10-21 04:37:23.0 + @@ -21,7 +21,7 @@ case "$1" in start) echo -n "Starting $DESC: " - start-stop-daemon --start --quiet --background --pidfile $PIDFILE --exec $DAEMON -- -c $DAEMON_CONFIG + start-stop-daemon --start --quiet --exec $DAEMON -- -c $DAEMON_CONFIG echo "$NAME." ;; stop) Running as user nobody works perfectly well. Chroots are broken as it does the chroot before it binds to the mysql socket so adding a note to reflect this. --- /root/deleted_stuff/etc/postfix-policyd.conf2007-10-21 03:23:52.0 + +++ /etc/postfix-policyd.conf 2007-10-21 04:33:31.0 + @@ -132,20 +132,22 @@ # directory to change to before binding # CHROOT=/ +#CHROOT=/var/empty +#Cannot connect to mysql unix socket in chroot # # uid: # # userid for the policy daemon to run as # -UID=0 +UID=65534 # # gid: # # groupid for the policy daemon to run as # -GID=0 +GID=65534 # # connection acl: Also upstream release notes not that the newer version 1.82 fixes a memory leak. sourceforge.net/project/shownotes.php?group_id=133598&release_id=533414 -- Daniel Black <[EMAIL PROTECTED]> Gentoo Foundation signature.asc Description: This is a digitally signed message part.
Bug#500882: DoS secuirty vulnerabilty 2.6.0-2.8.0
Package: dkim-filter Version: 2.6.0.dfsg-1 http://sourceforge.net:80/project/shownotes.php?group_id=139420&release_id=654247 Mike, as you discovered 2.6.0-2.8.0 has a DoS security vulnerability. Can this be fixed in lenny/etch-backports please? Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516503: /etc/sympa/general_task_models should be named /etc/sympa/global_task_models
Package: sympa Version: 5.3.4-5 Severity: normal Global task models according to the documentation should be in the global_task_models directory. Installing the directory /etc/sympa/general_task_models is confusing and won't work as replacement for global_task_models. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages sympa depends on: ii adduser 3.102Add and remove users and groups ii debconf [debconf-2. 1.5.11etch2 Debian configuration management sy ii libarchive-zip-perl 1.16-1 Module for manipulation of ZIP arc ii libc6 2.3.6.ds1-13etch9+b1 GNU C Library: Shared libraries ii libcgi-fast-perl5.8.8-7etch6 CGI::Fast Perl module ii libcrypt-ciphersabe 0.61-4 Perl module implementing CipherSab ii libdbd-mysql-perl 3.0008-1 A Perl5 database interface to the ii libdbi-perl 1.53-1etch1 Perl5 database interface by Tim Bu ii libintl-perl1.16-1 Uniforum message translations syst ii libio-stringy-perl 2.110-2 Perl5 modules for IO from scalars ii libmailtools-perl 1.74-1 Manipulate email in perl programs ii libmd5-perl 2.03-1 backwards-compatible wrapper for D ii libmime-charset-per 1.006.2-2Charset Informations for MIME ii libmime-encwords-pe 1.010.101-1 deal with RFC-1522 encoded words ii libmime-perl5.420-0.1Perl5 modules for MIME-compliant m ii libmsgcat-perl 1.03-3 Locale::Msgcat perl module ii libnet-ldap-perl1:0.33-2 A Client interface to LDAP servers ii libtemplate-perl2.14-1 template processing system written ii libxml-libxml-perl 1.59-2 Perl module for using the GNOME li ii lsb-base3.1-23.2etch1Linux Standard Base 3.1 init scrip ii mhonarc 2.6.16-1 Mail to HTML converter ii perl [libmime-base6 5.8.8-7etch6 Larry Wall's Practical Extraction ii perl-suid 5.8.8-7etch6 Runs setuid Perl scripts ii postfix [mail-trans 2.4.6-2~bpo40+1 High-performance mail transport ag ii sysklogd [system-lo 1.4.1-18 System Logging Daemon Versions of packages sympa recommends: pn doc-base (no description available) ii logrotate 3.7.1-3Log rotation utility -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516513: /var/lib/sympa/expl/X509-user-certs not created in default install
Package: sympa Version: 5.3.4-5 Severity: normal /var/lib/sympa/expl/X509-user-certs should be created owned by sympa:sympa. This is where the sympa process stores user certificates. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages sympa depends on: ii adduser 3.102Add and remove users and groups ii debconf [debconf-2. 1.5.11etch2 Debian configuration management sy ii libarchive-zip-perl 1.16-1 Module for manipulation of ZIP arc ii libc6 2.3.6.ds1-13etch9+b1 GNU C Library: Shared libraries ii libcgi-fast-perl5.8.8-7etch6 CGI::Fast Perl module ii libcrypt-ciphersabe 0.61-4 Perl module implementing CipherSab ii libdbd-mysql-perl 3.0008-1 A Perl5 database interface to the ii libdbi-perl 1.53-1etch1 Perl5 database interface by Tim Bu ii libintl-perl1.16-1 Uniforum message translations syst ii libio-stringy-perl 2.110-2 Perl5 modules for IO from scalars ii libmailtools-perl 1.74-1 Manipulate email in perl programs ii libmd5-perl 2.03-1 backwards-compatible wrapper for D ii libmime-charset-per 1.006.2-2Charset Informations for MIME ii libmime-encwords-pe 1.010.101-1 deal with RFC-1522 encoded words ii libmime-perl5.420-0.1Perl5 modules for MIME-compliant m ii libmsgcat-perl 1.03-3 Locale::Msgcat perl module ii libnet-ldap-perl1:0.33-2 A Client interface to LDAP servers ii libtemplate-perl2.14-1 template processing system written ii libxml-libxml-perl 1.59-2 Perl module for using the GNOME li ii lsb-base3.1-23.2etch1Linux Standard Base 3.1 init scrip ii mhonarc 2.6.16-1 Mail to HTML converter ii perl [libmime-base6 5.8.8-7etch6 Larry Wall's Practical Extraction ii perl-suid 5.8.8-7etch6 Runs setuid Perl scripts ii postfix [mail-trans 2.4.6-2~bpo40+1 High-performance mail transport ag ii sysklogd [system-lo 1.4.1-18 System Logging Daemon Versions of packages sympa recommends: pn doc-base (no description available) ii logrotate 3.7.1-3Log rotation utility -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#493251: [python-urlgrabber] https links for urlopen
according to other references m2crypt seems to be a requirement. http://www.nabble.com/Bug-in-HTTPSHandler-td15779972.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#971255: Acknowledgement (kopanocore: autopkgtest fails on assuming /etc/init.d/mysql exists)
I don't think so. There's no case for it. In the direction of eliminating mysql names in MariaDB let's not take a step back. On Sun, Oct 4, 2020 at 9:04 PM Otto Kekäläinen wrote: > > Hello! > > Any comments to this > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971255 from anyone? > > Should we revert back to shipping /etc/init.d/mysql on fresh installs as well?
Bug#933151: mariadb-10.3: FTBFS on riscv64
https://jira.mariadb.org/browse/MDEV-23892 created for this issue. https://github.com/MariaDB/server/pull/979 modified to be more minimal https://github.com/MariaDB/server/commit/970984e9f9b385d7a64d896baa437a40d65d3f2f is now in testing. Comments welcome. Testing on riscv64 is also very welcome. On Mon, Oct 5, 2020 at 7:14 AM Otto Kekäläinen wrote: > > Hello! > > I plan to upload mariadb-10.5 1:10.5.5-2 in a couple of days and I > would be happy to receive merge requests regarding getting riscv64 to > build properly on Debian. > > http://bugs.debian.org/933151 > https://wiki.debian.org/Teams/MySQL/patches > > > ti 29. syysk. 2020 klo 16.48 Otto Kekäläinen (o...@debian.org) kirjoitti: > > > > Hello! > > > > Adding Christian and Dimitri to the recipients, since I think it was > > Dimitri who patched the Ubuntu version of cmake for this. > > > > > > ti 29. syysk. 2020 klo 0.22 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > > > > > On 2020-09-28 15:12, Otto Kekäläinen wrote: > > > > After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still > > > > fails with these: > > > > > > > > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined > > > > reference to `__atomic_compare_exchange_1' > > > > > > > > The odd thing is that an identical build on Ubuntu Groovy passes OK: > > > > https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz > > > > > > Ubuntu has patched their version of cmake to link with -latomic on > > > riscv64. While patching cmake is a really good idea, the fix is wrong, > > > the correct think to do is to link with -pthread instead of -lpthread, > > > and do that for all architectures. > > > > > > This is the strategy followed for mariadb-10.5 in the attached patch. I > > > have tested it and it builds fine on Debian. > > > > -- > - Otto
Bug#933151: mariadb-10.3: FTBFS on riscv64
Thanks for the tests. Looks like removing the rocksdb part of the patch was overly ambitious. Also need atomics on the unittest/mysys/my_atomic-t.c I've updated: https://github.com/MariaDB/server/tree/bb-10.3-danielblack-MDEV-23892-pr979 aka https://github.com/MariaDB/server/commit/6171ecee13aea76d474919235568509835b25d98 I'm running a little blind without the CI so I appreciate your help. On Wed, Oct 7, 2020 at 5:30 AM Otto Kekäläinen wrote: > > Hello! > > ti 6. lokak. 2020 klo 14.41 Otto Kekäläinen (o...@debian.org) kirjoitti: > > > > Thanks Daniel! > > > > I applied it in > > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903 > > and tested on Launchpad to ensure that it does not at least regress :) > > https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=&build_state=all > > > > I will soon upload mariadb-10.5 1:10.5.5-2 and then we will get a > > result of all archs. > > Unfortunately 1:10.5.5-2 with the patch above failed to build on > riscv64 in Debian: > https://buildd.debian.org/status/package.php?p=mariadb-10.5
Bug#970662:
I noticed and wrote https://jira.mariadb.org/browse/MDEV-23900 covering this
Bug#975063:
fixed per upstream in 10.5.9
Bug#991839: [debian-mysql] Bug#991839: mariadb-server-10.3: MariaDB intermittantly not starting on boot on AWS EC2 t2.medium instance
Jeremy,
You are correct in that this is due to one of the hardening directives
in the service file Protect{Home,System} or PrivateDevices that is
trying to be applied before the kernel/system has completed the
underlying mounts on which they depend.
Without these hardening directives, and without
PermissionsStartOnly=true and all of the ExecStartPre= directives the
system is pretty secure as the mysqld/mariadbd process is run under
the non-privileged mysql user which ordinary cannot perform the
restricted items. Being a tiny VM I'm assuming this is the only
services there.
systemd-analyze dump (hint from
https://freedesktop.org/wiki/Software/systemd/Debugging/#reportingsystemdbugs-
Information to Attach to a Bug Report) may include some timing
information of services to verify. The logs since boot `journalctl -b`
might give enough information to see what ordering is happening at
boot.
kernel argument systemd.log_level=debug will include more information
in the mariadb.service journal `journalctl -u mariadb.service
--priority=7` such that the specific mount/system call might be able
to be identified. systemd.log_level=debug will probably make the
journalctl -b too verbose to read
Bug#990763:
Hi,
MDEV-25394 is dissimilar. It is in InnoDB while this appears to be in
the optimizer code.
A new 10.3.31 is coming soon
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/273217
The optimizer related fixes in the two version since 10.3.29 are:
https://jira.mariadb.org/issues/?jql=fixVersion%20%20in%20(10.3.30%2C%2010.3.31)%20and%20component%20%3D%20Optimizer
Looking at these bugs I can't see anything that looks particularly equivalent.
So in summary, we do need more information to resolve this. Ideally
this should be a new MDEV project bug on https://jira.mariadb.org/.
The information that would be most useful is:
* the query that caused this. This should of been in the log
* `SHOW CREATE TABLE {tablename}` for the table is the query.
* EXPLAIN EXTENDED {query}; SHOW WARNINGS
The stack trace shows this is occurring as a prepared statement. If
you are willing to risk the availability of the server running this as
a non-prepared statement straight from the mariadb command line that
would be useful as a test point.
If the core file is still available/reproducible the following
additional resolution of the stack traces that will aid MariaDB staff.
cat >>/etc/apt/sources.list.d/debug.list <<'EOT'
deb http://deb.debian.org/debian-debug buster-debug main contrib non-free
EOT
apt-get install -y gdb mariadb-server-core-10.3-dbg
gdb /usr/sbin/mysqld core
thread apply all bt full
The dbg symbols and gdb resolution can be on a different server or
even in a container that can access the core.
If this contains confidential information like tablenames (its
unlikely to contain table contents) of your client you can use
https://mariadb.com/kb/en/meta/mariadb-ftp-server/ to make this only
available to MariaDB people for the purpose of debugging this issue.
Bug#977178:
RocksDB level fix: https://github.com/facebook/rocksdb/commit/29f7bbef995bdf83098963799c66af742e95373f The rocksdb submodule within mariadb is significantly older however - https://github.com/MariaDB/server/tree/10.3/storage/rocksdb and I don't know the update policy on it.
Bug#984996: [debian-mysql] Bug#984996: mariadb-server-core-10.5: modifies globalö environment, causing race conditions
On Fri, Mar 12, 2021 at 6:51 AM Otto Kekäläinen wrote: > Hello! > > Thanks for reviewing the systemd scripts in MariaDB. I added a couple > of MariaDB devs as the systemd service files are not maintained in > Debian but inherited from upstream MariaDB. > > On Thu, 11 Mar 2021 at 19:42, Marc Lehmann > wrote: > > > > Package: mariadb-server-core-10.5 > > Version: 1:10.5.9-1 > > Severity: normal > > > > Dear Maintainer, > > > >* What led up to the situation? > > > > various scripts (e.g. galera_new_cluster) and the systemd.unit modify the > > global/systemwide environment, e.g. with variables _WSREP_START_POSITION. > > > > This has the effect of polluting the environment of other sservices with > > these variables, which is usually pretty harmless. > The intent was for minimal effects. > However, if there are multiple server instances then this creates a race > > condition Multiinstance services use _WSREP_START_POSITION%I as the environment name ref: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/master/support-files/mari...@.service.in#L88 > where starting/stopping one server or bootstrapping one cluster > > will interfere with the other instance,s which could easily lead to > > database corruption. > I'm not convinced about it easily. There are aria and innodb locks on filesystem preventing a second process modifying an already running process. Also the state only exists within the startup process of the mariadb.service. There are systemd blocks that prevent two copies of the same service starting at the same time. Maybe you mean something I haven't thought of. Can you explain the scenario? >* What exactly did you do (or not do) that was effective (or > > ineffective)? > > > > I didn't try to solve the problem, it seems to be too fundamental to > > easily work around. The mechanism (systemd environment block) is wholly > > unsuitable to solve this problem. > I know it's unclean. Suggestions welcome as to how to communicate state between two separate ExecStart* states in systemd welcome. note: * Filesystem ways need to prevent using the datadir which could be a place for a SST to be rsynced * You can't export environment between ExecStart scripts * Codership are quite unaccepting of contributions (e.g: https://github.com/codership/galera/pull/109). https://jira.mariadb.org/browse/MDEV-14707 has never come up with concrete improvements. And there's been no bugs that I've found reported against the operation of the functionality. > > >* What was the outcome of this action? > > > > Environment polluted, One environment variable of a constrained name. Pollution? That appears for the microscopic time between a couple service script starts and is gone by the time the service start? Pollution, really? critical environment variables of other services > > erased/modified. > Nothing else is modified or erased as you've already seen >* What outcome did you expect instead? > > > > A systemd service should _never_ _ever_ modify the global environment. I agree. But an exaggerated purist argument to fix a problem that doesn't have a concrete real or theoretical failure isn't going to get a high priority.
Bug#1020831: linux-signed-arm64: iouring tmpfs pwrite returns 125 error sparaticly
Package: linux-signed-arm64
Dear Maintainer,
This is derived from https://jira.mariadb.org/browse/MDEV-29610
MariaDB-10.6+ uses liburing as its default async IO layer. In our CI
infrastructure there are a considerable amount of encryption.innodb*
test errors where uring returns the error IO Error: 125 during async
write of 49152 bytes, for file 11, returned 0. In all cases this is
a pwrite uring call.
We are using various distro containers on the Debian kernel host and
this is a common error.
An example error is:
https://buildbot.mariadb.org/#/builders/482/builds/1493
The encryption.innodb-checksum-algorithm error where the complete
mariadb log is https://ci.mariadb.org/28662/logs/aarch64-rhel-9/mysqld.1.err.6
In this case the kernel versions is printed just before the next
test as:
* 5.10.0-17-cloud-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debi
A KVM build with a bullseye is:
https://buildbot.askmonty.org/buildbot/builders/kvm-deb-bullseye-aarch64/builds/111
Its kernel version is: 5.10.0-17-arm64 (debian-ker...@lists.debian.org)
Though largely aarch failures have been observed there are ppc64le
examples like:
* https://buildbot.mariadb.org/#/builders/478/builds/1676 error log
https://ci.mariadb.org/28662/logs/ppc64le-rhel-9/mysqld.1.err.11
Linux version 5.10.0-18-powerpc64le (debian-ker...@lists.debian.org)
The one amd64 case is in:
https://ci.mariadb.org/28153/logs/amd64-debian-sid/mysqld.1.err.14
The kernel (though not in the logs) was 5.10.0-13-amd64
(debian-ker...@lists.debian.org)
Our CI works across quite a number of host kernels and the Debian 5.10
is the only one showing these errors. Even newer kernels like
5.18.0-0.deb11 / Debian 5.18.16-1~bpo11+1 (2022-08-12)
isn't showing errors.
So its looking like a missing upstream iouring patch missing.
To reproduce:
(mariadb-10.6+ test)
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | bash
apt-get install -y mariadb-test patch
cd /usr/share/mysql/mysql-test/
mkdir var
chown mysql: var
as mysql user:
./mtr --mem --repeat=1000 --parallel=8
encryption.innodb-compressed-blob{,}
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux version 5.10.0-17-arm64
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Bug#1006529:
2023-02-01 0:35:16 0 [Warning] mariadbd: Couldn't allocate 8388608 bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing I believe it is a kernel bug. MariaDB is reading the page size from /sys/kernel/mm/hugepages. mapflag= MAP_PRIVATE | OS_MAP_ANON; mapflag|= my_bit_log2_size_t(large_page_size) << MAP_HUGE_SHIFT; ptr= mmap(NULL, aligned_size, PROT_READ | PROT_WRITE, mapflag, -1, 0); aligned_size is a memory size that is an increment of the page size. Per the mmap(2) man page, a ENOMEM, if memory cannot be allocated. EINVAL (22) is totally unexpected. From man page, the only condition satisfiable under the above conditions is length is too large (8M? seems unlikely), or not aligned on the page boundary. Given the page boundary was obtained from the /sys/kernel/mm/hugepages I'm out of explanations. Can you validate that the pages sizes on the directories in /sys/kernel/mm/hugepages are true to the architecture specification. I looked at kernel at mm/mmap.c and also can't see which path is returning EINVAL
Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))
btw, I never said it was the same bug. Given this was a hang and the MDEV-30728 was a corrupted page read it's likely to be different.
Bug#1032104: linux: ppc64el iouring corrupted read
Source: linux Version: 5.10.0-21-powerpc64le Severity: grave Justification: causes non-serious data loss X-Debbugs-Cc: dan...@mariadb.org Dear Maintainer, *** 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 *** >From https://jira.mariadb.org/browse/MDEV-30728 MariaDB's mtr tests on a number of specific tests depend on the correct kernel operation. As observed in these tests, there is a ~1/5 chance the encryption.innodb_encryption test will read zeros on the later part of the 16k pages that InnoDB uses by default. This affects MariaDB-10.6+ packages where there is a liburing in the distribution. This has been observed in the CI of Debian (https://ci.debian.net/packages/m/mariadb/testing/ppc64el/) and upstreams https://buildbot.mariadb.org/#/builders/318. The one ppc64le worker that has the Debian 5.10.0-21 kernel, the same as the Debian CI, has the prefix ppc64le-db-bbw1-*. Test faults occur on all MariaDB 10.6+ builds in containers on this kernel. There a no faults on non-ppc64le or RHEL7/8 based ppc64le kernels. To reproduce: apt-get install mariadb-test cd /usr/share/mysql/mysql-test ./mtr --mysqld=--innodb-flush-method=fsync --mysqld=--innodb-use-native-aio=1 --vardir=/var/lib/mysql --force encryption.innodb_encryption,innodb,undo0 --repeat=12 A test will frequenty fail. 2023-02-28 1:41:01 0 [ERROR] InnoDB: Database page corruption on disk or a failed read of file './ibdata1' page [page id: space=0, page number=282]. You may have to recover from a backup. (the page number isn't predictable) The complete mtr error log of mariadb server is $PWD/var/log/mysqld.1.err I tested on tmpfs. This is a different fault from bug #1020831 as: * there is no iouring error, just a bunch of zeros where data was expected. * this is ppc64le only. Note, more serious faults exist on overlayfs (MDEV-28751) and remote filesystems so sticking to local xfs, ext4, btrfs is recommended. -- System Information: Debian Release: bullseye APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: ppc64el (ppc64le) Kernel: Linux 5.10.0-21-powerpc64le (SMP w/128 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#1032104: linux: ppc64el iouring corrupted read
On Tue, Feb 28, 2023 at 5:24 PM Diederik de Haas wrote: > > On Tuesday, 28 February 2023 04:13:18 CET Daniel Black wrote: > > Source: linux > > Version: 5.10.0-21-powerpc64le > > Severity: grave > > Justification: causes non-serious data loss > > X-Debbugs-Cc: dan...@mariadb.org > > > > >From https://jira.mariadb.org/browse/MDEV-30728 > > > > MariaDB's mtr tests on a number of specific tests depend on the correct > > kernel operation. > > > > As observed in these tests, there is a ~1/5 chance the > > encryption.innodb_encryption test will read zeros on the later part of > > the 16k pages that InnoDB uses by default. > > > > This affects MariaDB-10.6+ packages where there is a liburing in the > > distribution. > > > > I tested on tmpfs. This is a different fault from bug #1020831 as: > > * there is no iouring error, just a bunch of zeros where data was > > expected. > > * this is ppc64le only. > > What was the last kernel where this problem did NOT occur? 2022-12-19 03:55:34 install linux-image-5.10.0-20-powerpc64le:ppc64el 5.10.158-2 no similar errors between ^ and .. 2023-01-24 03:19:59 install linux-image-5.10.0-21-powerpc64le:ppc64el 5.10.162-1 (no other linux image installs in between these two) first failure found ~ Feb 4 2023. Unsure when kernel rebooted to this kernel bug it does appear to be the last revision. https://buildbot.mariadb.org/#/builders/318/builds/10008 log example https://ci.mariadb.org/32263/logs/ppc64le-debian-11/mysqld.1.err.7 (search for CURRENT_TEST: encryption.innodb_encryption) - contains hex dump of page > It's probably needed to pinpoint the (upstream) commit that caused this error/ > issue and the best start is normally finding the closest range with Debian > kernel releases where it did not and did occur. > > > -- System Information: > > Debian Release: bullseye > > APT prefers jammy-updates > > APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, > > 'jammy'), (100, 'jammy-backports') Architecture: ppc64el (ppc64le) > > > > Kernel: Linux 5.10.0-21-powerpc64le (SMP w/128 CPU threads) > > Init: unable to detect > > Why is there no 'bullseye' in APT policy's output? > Mixing distrubutions (aka FrankenDebian) isn't recommended, but seeing no > bullseye in there is odd, especially since the kernel version very much does > look like Debian. Apologies for the FrankenDebian look. This was a jammy container and jammy report bug with bullseye edited (badly) in the system info.
Bug#1032104: linux: ppc64el iouring corrupted read
Since revering to linux-image-5.10.0-20 we've been free of the same errors.
Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))
Some crashes in the signal handler are the just created "MDEV-30613 output_core_info crashes in my_read()" with a probable cause. Doesn't help the original crash reason however. A single thread backtrace isn't sufficient on errors like: " InnoDB: innodb_fatal_semaphore_wait_threshold was exceeded for dict_sys.latch" With MTR_PRINT_CORE=detailed in the environment will do multiple threads and be more likely to identify deadlocks between processes (or if the builder is just very slow at this point). Disabling performance schema -DPLUGIN_PERFSCHEMA=NO on s390x might be a way to get some breathing space on this optional feature to resolve later as the unmap crashes seem firmly in this feature's shutdown.
Bug#1029164: Main. and order_by_innodb testing
Rex has created a commit to try to identify the cause of the problem in the main.order_by_innodb tests: https://github.com/MariaDB/server/commit/a0300390b5efbd7b408cb166e0ee715364a85f3c I don't know if salsa supports this, but a PR is https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/35. If this could be applied and Rex notified of the build logs that would be great.
Bug#996951:
Marko tested this is fixed in linux-image-5.14.0-4-amd64 (5.14.16-1). Thanks for the update. https://jira.mariadb.org/browse/MDEV-26674?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=204907#comment-204907
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
On Thu, Mar 3, 2022 at 8:16 AM John Paul Adrian Glaubitz wrote: > > Hello! > > On 3/2/22 21:14, Otto Kekäläinen wrote: > > A recent build regression on ppc64el is preventing a new MariaDB version > > from migrating from unstable to testing. > > > > Could any experts on this list help out? > > I don't know where this code is coming from, but this is definitely wrong: > > > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L145 > > The code is forcing compiler flags based on the architecture and thus > overriding the > baseline. This is a baseline violation and not allowed per Debian Policy. > > And, in particular, it violates the baseline of the ppc64 port which is using > POWER5, > not POWER8. John, The selective CFLAGS on specific files are there to enable optimizations in certain functions. Elsewhere in the code there is runtime detection made of the VSX/vpmsum to actually use the code. So for POWER5 it should be there but dormant. Likewise for the bug here. We've got a htmxlintrin.h header insisting on the -mhtm, backed up the compiler that doesn't define the __builtin_tbegin builtins without the cflags. We use the htm target function attribute to compile specific functions that use it, however the use of instructions is still behind a runtime check. We can't include the header check inside a function, otherwise we are defining an inline function within a function. My work in progress fix is along these lines: https://github.com/MariaDB/server/commit/6df3911b61ba669285c08b1456276217c7881292 note just below the standard view of this commit at the bottom, there is transactional_lock_enabled that does runtime detection. But it's still failing (https://buildbot.mariadb.org/#/grid?branch=bb-10.6-danielblack-MDEV-27936-ppc64-htm-build-fail , for sid only, and only recent (https://buildbot.mariadb.org/#/grid?branch=10.6)), proving sid is true to its name. If this still violates the policy, I'd like to know now so I can implement solutions that drop support for ppc64 POWER5+ and support hardware like ppc64le, POWER8+ that we actually do have hardware for and can support.
Bug#1006702:
They won't crash, because the CPU features are tested before any call to the optimized code is made. https://github.com/MariaDB/server/blob/10.6/mysys/crc32/crc32c.cc#L542-L564 As the Debian CI undoubtedly runs the basic unit tests that cover crc32 on the minimum hardware, and succeeds, it proves the autodetection is correct.
Bug#1007216:
The next and build log succeeds https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6&arch=ppc64&ver=1%3A10.6.7-3&stamp=1647203640&raw=0 The remaining test failure main.func_json_notembedded has a fix waiting (MDEV-27955) When I see a SIGILL in a test case I'll believe it's incorrectly called. In the meantime I believe the runtime checks are there.
Bug#1006530:
The error is earlier in the logs: -- Looking for sched_getcpu - found -- Could NOT find PMEM (missing: PMEM_LIBRARIES PMEM_INCLUDE_DIR) CMake Error at storage/innobase/CMakeLists.txt:345 (MESSAGE): WITH_PMEM=ON cannot be satisfied When the configure stage fails, the builds outputs the CMakeOutput/Error logs to complement this error earlier in the logs. In this case its not useful but other times it is. so the architecture test in debian/rules isn't right as it adds WITH_PMEM=ON.
Bug#1006531:
Actual error earlier in logs: -- Performing Test HAVE_PEERCRED -- Performing Test HAVE_PEERCRED - Failed -- Performing Test HAVE_SOCKPEERCRED -- Performing Test HAVE_SOCKPEERCRED - Failed -- Performing Test HAVE_XUCRED -- Performing Test HAVE_XUCRED - Failed -- Performing Test HAVE_UNPCBID -- Performing Test HAVE_UNPCBID - Failed -- Performing Test HAVE_GETPEERUCRED -- Performing Test HAVE_GETPEERUCRED - Failed -- Performing Test HAVE_GETPWUID_POSIX_FINAL -- Performing Test HAVE_GETPWUID_POSIX_FINAL - Failed -- Performing Test HAVE_PEERCRED_STRUCT -- Performing Test HAVE_PEERCRED_STRUCT - Failed CMake Error at cmake/plugin.cmake:327 (MESSAGE): Plugin AUTH_SOCKET cannot be built Call Stack (most recent call first): CMakeLists.txt:434 (CONFIGURE_PLUGINS) So no known AUTH_SOCKET implementation on hurd is there, but the authentication is forced on.
Bug#1002087: Fwd: MariaDB 10.6 regressed ruby-mysql2
-- Forwarded message - From: Daniel Black Date: Thu, Dec 23, 2021 at 10:40 AM Subject: Re: MariaDB 10.6 regressed ruby-mysql2 To: Otto Kekäläinen Cc: , Tuukka Pasanen , Faustin Lammler expected Mysql2::Error with message matching /Lost connection to MySQL server/, got # with backtrace: Our error message changed. ruby-mysql2 already fixed the test upstream - https://github.com/brianmario/mysql2/commit/cca57b97ad6d1b1b985376be110b89d2b487dea6 On Thu, Dec 23, 2021 at 4:47 AM Otto Kekäläinen wrote: > > Hello! > > Looking at https://tracker.debian.org/pkg/mariadb-10.6 it seems mariadb > 1.10.6.5-2 is currently blocked from progressing from Debian unstable to > testing due to Debian-CI/autopkgtests failures on package ruby-mysql2. > > This is a regression from 10.5. Could somebody please investigate? > > - Otto
Bug#933151: mariadb-10.3: FTBFS on riscv64
I'm probably going to add a fix to https://github.com/MariaDB/server/blob/10.5/configure.cmake#L865 to include libatomic globally if needed. AIX needs it too. On Mon, Sep 21, 2020 at 7:56 AM Otto Kekäläinen wrote: > > Package: mariadb-10.5 > Version: 1:10.5.5-1~exp1 > > The riscv64 builds on Debian build are still failing for latest mariadb-105: > https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=riscv64&ver=1%3A10.5.5-1%7Eexp1&stamp=1599937965&raw=0 > > > > [ 62%] Building CXX object > storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o > cd /<>/builddir/storage/mroonga && > /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H > -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED > -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1 > -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS > -I/<>/wsrep-lib/include > -I/<>/wsrep-lib/wsrep-API/v26 > -I/<>/builddir/include > -I/<>/builddir/storage/mroonga > -I/<>/storage/mroonga > -I/<>/storage/mroonga/lib -I/<>/include > -I/<>/sql -I/<>/regex -I/<> > -I/<>/storage/mroonga/vendor/groonga/include > -I/<>/builddir/extra/wolfssl > -I/<>/extra/wolfssl/wolfssl > -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie > -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g > -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing > -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 > -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation > -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter > -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC > -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -o > CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o -c > /<>/storage/mroonga/lib/mrn_operation.cpp > /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function > `rocksdb::ConcurrentArena::ApproximateMemoryUsage() const': > ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/memory/concurrent_arena.h:67: > undefined reference to `__atomic_compare_exchange_1' > /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function > `std::__atomic_base::compare_exchange_weak(bool&, bool, > std::memory_order, std::memory_order)': > /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to > `__atomic_compare_exchange_1' > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined > reference to `__atomic_compare_exchange_1' > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined > reference to `__atomic_compare_exchange_1' > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined > reference to `__atomic_compare_exchange_1' > /usr/bin/ld: > librocksdblib.a(memtable.cc.o):/usr/include/c++/10/bits/atomic_base.h:464: > more undefined references to `__atomic_compare_exchange_1' follow > [ 62%] Building CXX object > storage/perfschema/CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o > cd /<>/builddir/storage/perfschema && > /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DEMBEDDED_LIBRARY > -DHAVE_CONFIG_H -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 > -I/<>/wsrep-lib/include > -I/<>/wsrep-lib/wsrep-API/v26 > -I/<>/builddir/include -I/<> > -I/<>/include -I/<>/sql > -I/<>/builddir/sql > -I/<>/builddir/storage/perfschema > -I/<>/builddir/extra/wolfssl > -I/<>/extra/wolfssl/wolfssl > -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie > -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g > -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing > -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 > -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation > -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter > -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings > -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_OPENSSL -DHAVE_WOLFSSL > -DWOLFSSL_USER_SETTINGS -fPIC -fvisibility=hidden -std=gnu++11 -o > CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o -c > /<>/storage/perfschema/pfs_engine_table.cc > [ 62%] Building CXX object > storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_database.cpp.o > cd /<>/builddir/storage/mroonga && > /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H > -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED > -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1 > -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS > -I/<>/wsrep-lib/include > -I/<>/wsrep-lib/wsrep-API/v26 > -I/<>/builddir/include > -I/<>/builddir/storage/mroonga > -I/<>/storage/mroonga > -I/<>/storage/mroonga/lib -I/<>/include > -I/<>/sql -I/<>/regex -I/<> > -I/<>/storage/mroonga/vendor/groonga/include > -I/<>/builddir/extra/wolfssl > -I/<>/extra/wolfssl/wolfssl > -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wdate
Bug#971255:
Providing a different sysvinit service name different from the systemd service name is a violation of the packaging guidelines https://wiki.debian.org/Teams/pkg-systemd/Packaging?action=show#systemd_unit_files_naming_and_installation Wasn't this covered already in https://github.com/MariaDB/server/pull/1494 / https://jira.mariadb.org/browse/MDEV-15526 ?
Bug#933151: mariadb-10.3: FTBFS on riscv64
Upstream PR is very welcome. Occasional nagging also.
Bug#996951: linux-image-5.14.0-3-amd64: iouring looses requests
Package: src:linux
Version: 5.14.12-1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: dan...@mariadb.org
Dear Maintainer,
MariaDB has been investigating a 10.6+ related problem for a while
https://jira.mariadb.org/browse/MDEV-26674
https://jira.mariadb.org/browse/MDEV-26555
The result of this investigation is that between 5.11 and fixed in 5.15
is a uring kernel related fault that results in a write request getting
lost.
The result of this is that MariaDB-10.6 users, and perhaps other
applications using the iouring kernel interface will loose either
availablity or data.
The good news is I've validated that the linux mainline 5.14.14 build
from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.14/ has
actually fixed this problem.
As such this affects bullseye-backports, bookworm and side currently.
This can be validated by installing mariadb-test-10.6 from MariaDB's
repo.
https://mariadb.org/download/#mariadb-repositories
To test run:
cd /usr/share/mysql/mysql-test
./mtr --vardir=/tmp/var --parallel=4 encryption.innochecksum{,}
./mtr --vardir=/tmp/var --parallel=4 stress.ddl_innodb stress.ddl_innodb
stress.ddl_innodb stress.ddl_innodb
A test failure (after a large timeout 10 mins I think) results in the
mariadb error:
2021-10-21 9:08:43 0 [ERROR] [FATAL] InnoDB:
innodb_fatal_semaphore_wait_threshold was exceeded for dict_sys.latch. Please
refer to https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/
Marko (MariaDB innodb maintainer) in
https://jira.mariadb.org/browse/MDEV-26674?focusedCommentId=202674&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-202674
already validated the problem on sid.
This is reported on an ubuntu impish machine with the Debian kernel
installed to eliminate any other userspace effects that may have caused
this.
-- Package-specific info:
** Version:
Linux version 5.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.3.0-11) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian
5.14.12-1 (2021-10-14)
** Command line:
BOOT_IMAGE=/vmlinuz-5.14.0-3-amd64 root=/dev/mapper/ubuntu--vg-ubuntu--lv ro
** Not tainted
** Kernel log:
[1.866883] ata4: SATA link down (SStatus 0 SControl 300)
[1.869434] scsi 0:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.5+
PQ: 0 ANSI: 5
[1.878673] ata6: SATA link down (SStatus 0 SControl 300)
[1.880335] ata5: SATA link down (SStatus 0 SControl 300)
[1.915393] sr 0:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[1.916496] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.958195] sr 0:0:0:0: Attached scsi CD-ROM sr0
[2.217095] input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/i8042/serio1/input/input3
[2.225457] pcieport :00:02.6: pciehp: Slot(0-6): No device found
[2.525250] raid6: avx2x4 gen() 29809 MB/s
[2.593249] raid6: avx2x4 xor() 13304 MB/s
[2.661249] raid6: avx2x2 gen() 34952 MB/s
[2.729248] raid6: avx2x2 xor() 20847 MB/s
[2.797248] raid6: avx2x1 gen() 29982 MB/s
[2.865248] raid6: avx2x1 xor() 16322 MB/s
[2.933259] raid6: sse2x4 gen() 14256 MB/s
[3.001247] raid6: sse2x4 xor() 8371 MB/s
[3.069248] raid6: sse2x2 gen() 14546 MB/s
[3.137248] raid6: sse2x2 xor() 8631 MB/s
[3.205249] raid6: sse2x1 gen() 12159 MB/s
[3.273248] raid6: sse2x1 xor() 6207 MB/s
[3.273649] raid6: using algorithm avx2x2 gen() 34952 MB/s
[3.274147] raid6: xor() 20847 MB/s, rmw enabled
[3.274552] raid6: using avx2x2 recovery algorithm
[3.278389] xor: automatically using best checksumming function avx
[3.282251] async_tx: api initialized (async)
[3.433164] Btrfs loaded, crc32c=crc32c-intel, zoned=yes
[3.667862] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
(null). Quota mode: none.
[3.759716] Not activating Mandatory Access Control as /sbin/tomoyo-init
does not exist.
[3.853765] systemd[1]: Inserted module 'autofs4'
[3.893289] systemd[1]: systemd 248.3-1ubuntu8 running in system mode. (+PAM
+AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL
+BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK
+PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON
+UTMP +SYSVINIT default-hierarchy=unified)
[3.895610] systemd[1]: Detected virtualization kvm.
[3.896183] systemd[1]: Detected architecture x86-64.
[3.907380] systemd[1]: Hostname set to .
[4.275407] systemd[1]: Queued start job for default target Graphical
Interface.
[4.278640] systemd[1]: Created slice system-modprobe.slice.
[4.284509] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[4.287754] systemd[1]: Created slice User and Session Slice.
[4.289457] systemd[1]: Started Forward Password Requests to Wall Directory
Watch.
[4.291130] systemd[1]: Set up automount Arbitrary Executable File F
Bug#996951: linux-image-5.14.0-3-amd64: iouring looses requests
retested 5.14.14. Sorry not fixed there yet. Guess this is going upstream. few other fixes to try: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/log/?h=io_uring-5.15 $ uname -a Linux impish 5.14.14-051414-generic #202110201037 SMP Wed Oct 20 11:04:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux dan@impish:/usr/share/mysql/mysql-test$ ./mtr --vardir=/tmp/var --parallel=4 stress.ddl_innodb stress.ddl_innodb stress.ddl_innodb stress.ddl_innodb Logging: ./mtr --vardir=/tmp/var --parallel=4 stress.ddl_innodb stress.ddl_innodb stress.ddl_innodb stress.ddl_innodb vardir: /tmp/var Removing old var directory... Creating var directory '/tmp/var'... Checking supported features... MariaDB Version 10.6.5-MariaDB-1:10.6.5+maria~impish - SSL connections supported - binaries built with wsrep patch Collecting tests... Installing system database... == TEST WORKER RESULT TIME (ms) or COMMENT -- worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 worker[4] Using MTR_BUILD_THREAD 301, with reserved ports 16020..16039 worker[3] Using MTR_BUILD_THREAD 302, with reserved ports 16040..16059 worker[2] Using MTR_BUILD_THREAD 303, with reserved ports 16060..16079 stress.ddl_innodb 'innodb' w4 [ pass ] 235134 stress.ddl_innodb 'innodb' w1 [ pass ] 245906 stress.ddl_innodb 'innodb' w3 [ pass ] 301078 stress.ddl_innodb 'innodb' w2 [ fail ] Test ended at 2021-10-21 11:23:30 .. Version: '10.6.5-MariaDB-1:10.6.5+maria~impish-log' socket: '/tmp/var/tmp/2/mysqld.1.sock' port: 16060 mariadb.org binary distribution 2021-10-21 11:09:42 0 [Note] InnoDB: Buffer pool(s) load completed at 211021 11:09:42 2021-10-21 11:23:27 0 [ERROR] [FATAL] InnoDB: innodb_fatal_semaphore_wait_threshold was exceeded for dict_sys.latch. Please refer to https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ 211021 11:23:27 [ERROR] mysqld got signal 6 ; On Thu, Oct 21, 2021 at 10:10 PM Diederik de Haas wrote: > > On Thursday, 21 October 2021 12:41:34 CEST Salvatore Bonaccorso wrote: > > On Thu, Oct 21, 2021 at 09:38:00AM +, Daniel Black wrote: > > > Package: src:linux > > > Version: 5.14.12-1 > > > The good news is I've validated that the linux mainline 5.14.14 build > > > from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.14/ has > > > actually fixed this problem. > > > > Where you able to isolate the upstream change landed upstream which > > fixes the issue? > > There has been 1 change in fs/io_uring.c that is part of 5.14.14 (and > 5.14.13), > but not 5.14.12 and that is this commit: > e798dcd960a3f0d40302a1bbf7f755879195a163 "io_uring: kill fasync" > > Possibly the simplest way to verify whether it's indeed that commit that fixes > the issue is to apply the patch to Debian's 5.14.12 kernel. > Instructions here (also follow 4.2.1): > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > This would narrow it down to this specific commit and would also rule out > differences in Ubuntu's kernel config and Debian's. > > Cheers, > Diederik
Bug#1022994: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
So what Fedora does is a prep script called at StartPre on their systemd service. https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb-prepare-db-dir.sh Which even recently was seen as bloated (https://lists.launchpad.net/maria-discuss/msg06376.html). What could be done is a oneshot (https://www.redhat.com/sysadmin/systemd-oneshot-service) service before MariaDB/MySQL that does the installation. Either installation or startup triggered. At least on TMPDIR side, the systemd side PrivateTmp is default (https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=) for at least the oneshot service. The option for loading files into MariaDB was the only reason this wasn't set in the default MariaDB systemd file. How User= systemd directives work with lbpam-tmpdir I'm not sure, however without a setuid there shouldn't be an invalid TMPDIR env variable there. Also not perfect, but maybe viable. On Sun, Nov 13, 2022 at 8:14 AM Otto Kekäläinen wrote: > > > > I think the answer to this should probably be established by the > > > libpam-tmpdir maintainer and documented first, for fear of someone else > > > later coming along and saying that the maintainer script incorrectly > > > ignores TMPDIR because we started ignoring it to resolve this bug. So I > > > copied debian-devel@ for comment. > > > > I'm not sure this is libpam-tmpdir specific, but rather a bit more > > general: what are the expectations that maintainer scripts can have > > about the environment they're running in, and how do we make those > > expectations hold? This should probably then be documented in policy. > > This MySQL 8.0 in Sid tmpdir issue is identical to MariaDB 10.6 in Sid > tmpdir issue, as they are based on historically the same maintainer > script. > > MariaDB duplicate of this has been filed as > https://jira.mariadb.org/browse/MDEV-29910 and > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022994 > > The suggested solution in > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/23 > to set an empty TMPDIR does not seem to work - or at least CI shows > that even a basic install fails after that. > > Instead of manually trying to manage TMPDIR env variable in various > places, we should have a standardized way to run maintainer scripts in > clean shell sessions that have all env variables set automatically > correctly. > > More proposals on how to handle this are welcome at > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests > :) > > - Otto
Bug#996951: linux-image-5.14.0-3-amd64: iouring looses requests
https://marc.info/?l=linux-block&m=163489378723217&w=2
Bug#837041: clang fails to compile atomics correctly
On 08/09/16 17:40, Sylvestre Ledru wrote: ... > This is working fine with 3.6. Sorry but I am not planning to fix that as 3.5 > is pretty old... > http://apt.llvm.org/ is providing up to date versions of clang. True, but not for ppc64le against which the bug was written. N: Skipping acquire of configured file 'main/binary-ppc64el/Packages' as repository 'http://apt.llvm.org/jessie llvm-toolchain-jessie InRelease' doesn't support architecture 'ppc64el' If http://apt.llvm.org could support ppc64le packages I'd be happy with that. I might even be able to help build them.
Bug#832931: (no subject)
As Thadeu Lima de Souza Cascardo said, the build time detected page size isn't correct, perhaps using --with-lg-page=/--with-lg-page-sizes at compile time. This is available in the 3.6.0 version of jemalloc. (upstream currently at 4.4.0). I've got part way though an upstream patch to change this to runtime detection, no idea when it will be complete, and I have been told that upstream won't risk performance regressions.
Bug#843926: (no subject)
As Thadeu Lima de Souza Cascardo said, the build time detected page size isn't correct, perhaps using --with-lg-page=/--with-lg-page-sizes at compile time. This is available in the 3.6.0 version of jemalloc. (upstream currently at 4.4.0). As an aside, I've got part way though an upstream patch to change this to runtime detection, no idea when it will be complete, and I have been told that upstream won't risk performance regressions.
Bug#612439:
For ref I did a comparison against the only long term supported 2.6.33+ kernel,
2.6.34.14 released 2013-01-16 (ref: https://www.kernel.org/). Note dm-snap got
merged into the 2.6.32 kernel on 2009-12-03.
Looking at changes in dm-snap.c
(https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/md/dm-snap.c?showmsg=1
), the log shows two performance improvements, an introduction of a throttling
mechanism and a bunch of code clean-ups.
dm-exception-store.c (
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/md/dm-exception-store.c
) contains two bug fixes.
dm-snap-persistent.c (
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/md/dm-snap-persistent.c?showmsg=1
)contains a prevention of disk corruption bug fix and moves to non-single
threaded work queues.
dm-snap-transient.c (
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/md/dm-snap-transient.c?showmsg=1
) added an include of export.h.
If you choose to use the 2.6.34.4 as the base for a backport, the same
procedure works with one more change is required due to an API change on
dm_get_device.
--- include/linux/device-mapper.h 2009-12-03 14:51:21.0 +1100
+++ ../linux-2.6.34.14/include/linux/device-mapper.h2013-01-17
08:55:31.0 +1100
@@ -118,10 +118,9 @@
/*
* Constructors should call these functions to ensure destination devices
* are opened/closed correctly.
- * FIXME: too many arguments.
*/
-int dm_get_device(struct dm_target *ti, const char *path, sector_t start,
- sector_t len, fmode_t mode, struct dm_dev **result);
+int dm_get_device(struct dm_target *ti, const char *path, fmode_t mode,
+struct dm_dev **result);
Basicly 0 for start and ti->len for length is added, the same as the original
use of dm_get_device in dm-snap.c. As indicated here:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/md/dm-snap.c?id=8215d6ec5fee1e76545decea2cd73717efb5cb42
these parameters aren't actually used.
So:
--- dm-snap.c-2.6.34.14 2013-03-30 15:06:09.0 +1100
+++ dm-snap.c 2013-03-30 15:08:41.0 +1100
@@ -1083,7 +1083,7 @@
argv++;
argc--;
- r = dm_get_device(ti, origin_path, origin_mode, &s->origin);
+ r = dm_get_device(ti, origin_path, 0, ti->len, origin_mode, &s->origin);
if (r) {
ti->error = "Cannot get origin device";
goto bad_origin;
@@ -1093,7 +1093,7 @@
argv++;
argc--;
- r = dm_get_device(ti, cow_path, FMODE_READ | FMODE_WRITE, &s->cow);
+ r = dm_get_device(ti, cow_path, 0, ti->len, FMODE_READ | FMODE_WRITE,
&s->cow);
if (r) {
ti->error = "Cannot get COW device";
goto bad_cow;
@@ -2111,7 +2111,7 @@
return -EINVAL;
}
- r = dm_get_device(ti, argv[0], dm_table_get_mode(ti->table), &dev);
+ r = dm_get_device(ti, argv[0], 0, ti->len,
dm_table_get_mode(ti->table), &dev);
if (r) {
ti->error = "Cannot get target device";
return r;
I copied dm-snap* and dm-exception* from a 2.6.34.4 kernel with the above
modification and INIT_WORK_ON_STACK -> INIT_WORK in dm-exception.c in the
linux-source-2.6.32 release. Used the /boot/config-2.6.32 with all modules
disabled except for BLK_DEV_MD, BLK_DEV_DM, DM_SNAPSHOT.
Moved the dm-snapshot.ko as above, depmod -a, modprobe -f dm-snaphot, and got
the same dmsetup table results.
Testing in a qemu-kvm vm:
lvcreate -s v/src -n src-snap -L 100M
lvs v
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
src vowi-ao 1.68g
src-snap vswi-a- 100.00m src 0.10
rm /usr/src/README .
lvconvert --merge v/src-snap
Can't merge over origin volume
Merging of snapshot src-snap will start next activitation
umount /usr/src
lvchange -an v/src
lvs v
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
src vOwi--- 1.68g
lvchange -ay v/src
mount /dev/v/src /usr/src
ls /usr/src
(showed files I deleted)
So the 2.6.34.4 is a suitable backport for dm-snaphot as above to allow merge
to origin.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705023: corosync-2.3.0 source package missing dependancy on libdbus-1-dev
Package: corosync Version: 2.3.0-1 Severity: serious Justification: fails to build from source While doing a backport of corosync-2.3.0-1 to squeeze I it wouldn't build and complained that dbus was missing. It seems libdbus-1-dev was missing from the dependancy list. -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages corosync depends on: ii adduser3.112+nmu2add and remove users and groups ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcfg62.3.0-1 Standards-based cluster framework, ii libcmap4 2.3.0-1 Standards-based cluster framework, ii libcorosync-common42.3.0-1 Standards-based cluster framework, ii libcpg42.3.0-1 Standards-based cluster framework, ii libdbus-1-31.2.24-4+squeeze2 simple interprocess messaging syst ii libnss3-1d 3.12.8-1+squeeze6 Network Security Service libraries ii libqb0 0.14.4-1 high performance client server fea ii libquorum5 2.3.0-1 Standards-based cluster framework, ii libsam42.3.0-1 Standards-based cluster framework, ii libstatgrab6 0.16-0.1 library being useful interface to ii libtotem-pg5 2.3.0-1 Standards-based cluster framework, ii libvotequorum6 2.3.0-1 Standards-based cluster framework, ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip corosync recommends no packages. corosync 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#705191: experimental pacemaker package depends on non-existant libcorosync(-dev)_2.3.0_2 and crmsh
Package: pacemaker Version: 1.1.9+git20130321-1 Severity: normal I was doing a backport that was going ok until these two missing dependancies. I probably can get around them but just reminding you in case you missed adding two packages. I'm about to write/put a bunch of patches in the pervent the excessive library linking into upstream pacemaker so watch out for them. pacemaker-1.1.7* won't work with corosync-2.3.0* due to missing libcoroipcc.so.4 (libcorosync4). Looking forward to a crmsh package too. Thanks for packaging corosync-2.3.0, libqb and pacemaker up. cman also doesn't work with corosync-2.* so I don't know if that needs restraining somewhere. -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pacemaker depends on: ii adduser 3.112+nmu2 add and remove users and groups ii corosync 2.3.0-1Standards-based cluster framework pn crmsh (no description available) ii libbz2-1.01.0.5-6+squeeze1 high-quality block-sorting file co ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcfg6 2.3.0-1Standards-based cluster framework, ii libcib3 1.1.9+git20130321-1Pacemaker libraries - CIB ii libcmap4 2.3.0-1Standards-based cluster framework, ii libcorosync-commo 2.3.0-1Standards-based cluster framework, ii libcpg4 2.3.0-1Standards-based cluster framework, ii libcrmcluster21.1.9+git20130321-1Pacemaker libraries - CRM ii libcrmcommon3 1.1.9+git20130321-1Pacemaker libraries - common CRM ii libcrmservice11.1.9+git20130321-1Pacemaker libraries - crmservice ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgnutls26 2.8.6-1+squeeze2 the GNU TLS library - runtime libr ii liblrmd1 1.1.9+git20130321-1Pacemaker libraries - lrmd ii libltdl7 2.2.6b-2 A system independent dlopen wrappe ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libpam0g 1.1.1-6.1+squeeze1 Pluggable Authentication Modules l ii libpe-rules2 1.1.9+git20130321-1Pacemaker libraries - rules for P- ii libpe-status4 1.1.9+git20130321-1Pacemaker libraries - status for P ii libpengine4 1.1.9+git20130321-1Pacemaker libraries - P-Engine ii libpils2 1.0.9+hg2665-1~bpo60+2 Reusable cluster libraries -- libp ii libplumb2 1.0.9+hg2665-1~bpo60+2 Reusable cluster libraries -- libp ii libqb00.14.4-1 high performance client server fea ii libquorum52.3.0-1Standards-based cluster framework, ii libstonithd2 1.1.9+git20130321-1Pacemaker libraries - stonith ii libtransitioner2 1.1.9+git20130321-1Pacemaker libraries - transitioner ii libuuid1 2.17.2-9 Universally Unique ID library ii libxml2 2.7.8.dfsg-2+squeeze7 GNOME XML library ii libxslt1.11.1.26-6+squeeze3 XSLT 1.0 processing library - runt ii pacemaker-cli-uti 1.1.9+git20130321-1Command line interface utilities f ii python2.6.6-3+squeeze7 interactive high-level object-orie ii python2.6 2.6.6-8+b1 An interactive high-level object-o ii resource-agents 1:3.9.2-5~bpo60+1 Cluster Resource Agents pacemaker recommends no packages. pacemaker suggests no packages. -- Configuration Files: /etc/default/pacemaker [Errno 2] No such file or directory: u'/etc/default/pacemaker' -- 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#705191: experimental pacemaker package depends on non-existant libcorosync(-dev)_2.3.0_2 and crmsh
1. Also missing from the pacemaker dependencies is libheartbeat2 This is dl loaded at the start of the runtime. >From log at pacemakerd startup: Apr 14 07:19:23 tx-web05 pacemakerd[5000]:error: find_library_function: Fatal: Could not open libhbclient.so.1: libhbclient.so.1: cannot open shared object file: No such file or directory I'm using 3.0.5-2~bpo60+1 from squeeze-backports which is working well. 2. Also starting pacemaker before corosync causes it to silently fail. 3. Also with libheartbeat2 dependencies libcorosync4 >= 1.4.2 is going to fail 2.0+ as no libs are included. libevs and libcoroipcc in wheezy, sid is sufficient and works. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612439:
After the kernel change previously described snapshot-origin is there. $ sudo dmsetup targets snapshot-merge v1.0.0 snapshot-origin v1.7.0 snapshot v1.9.0 striped v1.3.0 linear v1.1.0 errorv1.0.1 $ uname -a Linux quoll 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612439:
I had the same problem an did a successful restore on a live system as follows:
apt-get install linux-source-2.6.32
This involved copying 5 files from the 2.6.33 kernel.org release in the
directory drivers/md :
dm-snap.c
dm-snap-persistent.c
dm-snap-transient.c
dm-exception-store.h
dm-exception-store.c
One change was needed in the dm-snap-persistent.c INIT_WORK_ON_STACK ->
INIT_WORK on line 257.
in the
cd /usr/src/linux-source-2.6.32
cp /boot//config-2.6.32-5-amd64 .config
make -j4
rmmod dm-snapshot
mv /lib64/modules/2.6.32-5-amd64/kernel/drivers/md/dm-snapshot.ko
/lib64/modules/2.6.32-5-amd64/kernel/drivers/md/dm-snapshot.ko.orig
mv drivers/md/dm-snapshot.ko
/lib64/modules/2.6.32-5-amd64/kernel/drivers/md/dm-snapshot.ko
depmod -a
modprobe dm-snapshot
After that the lvchange -ay {volume} worked.
Though there's a reasonable amount of code change there in dm-snapshot most of
it is adding the merge to origin code and the rest is unaffected. I'd do
further comparisons against later kernel versions to see if there's any
regressions but for the time being this fixed my problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739730: corosync: example files contain log path to non-existent directory /var/log/cluster
Package: corosync
Version: 1.4.2-3
Severity: minor
{/etc/corosync,/usr/share/docs/corosync/examples}/corosync.conf.example*
contains the path /var/log/cluster/corosync.log
Because /var/log/cluster doesn't exist the rather unspecific error is returned.
[] Restarting corosync daemon: corosyncparse error in config: parse error
in config: .
Feb 22 00:05:23 corosync [MAIN ] Corosync Cluster Engine ('1.4.2'): started
and ready to provide service.
Feb 22 00:05:23 corosync [MAIN ] Corosync built-in features: nss
Feb 22 00:05:23 corosync [MAIN ] Successfully read main configuration file
'/etc/corosync/corosync.conf'.
Feb 22 00:05:23 corosync [MAIN ] parse error in config: parse error in config:
.
Feb 22 00:05:23 corosync [MAIN ] Corosync Cluster Engine exiting with status 8
at main.c:1680.
Can you please create its own directory and/or reset the path in examples to
/var/log/corosync.log ?
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.12.9-x86_64-linode37 (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 corosync depends on:
ii adduser 3.113+nmu3
ii libc6 2.13-38+deb7u1
ii libcfg4 1.4.2-3
ii libconfdb4 1.4.2-3
ii libcoroipcc41.4.2-3
ii libcoroipcs41.4.2-3
ii libcpg4 1.4.2-3
ii libevs4 1.4.2-3
ii liblogsys4 1.4.2-3
ii libpload4 1.4.2-3
ii libquorum4 1.4.2-3
ii libsam4 1.4.2-3
ii libtotem-pg41.4.2-3
ii libvotequorum4 1.4.2-3
ii lsb-base4.1+Debian8+deb7u1
corosync recommends no packages.
corosync suggests no packages.
-- Configuration Files:
/etc/corosync/corosync.conf changed [not included]
/etc/default/corosync changed [not included]
-- 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#739731: pacemaker needs corosync service definition in corosync.conf
Package: pacemaker
Version: 1.1.7-1
Severity: minor
For pacemaker to provide a working crm interface the following is needed in the
corosync configuration.
Adding the following would assist in this matter.
Install the following contents in /etc/corosync/service.d/pacemaker.conf:
service {
# Load the Pacemaker Cluster Resource Manager
name: pacemaker
ver: 1
}
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.12.9-x86_64-linode37 (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 pacemaker depends on:
ii adduser 3.113+nmu3
ii corosync 1.4.2-3
ii libbz2-1.01.0.6-4
ii libc6 2.13-38+deb7u1
ii libcfg4 1.4.2-3
ii libcib1 1.1.7-1
ii libconfdb41.4.2-3
ii libcoroipcc4 1.4.2-3
ii libcpg4 1.4.2-3
ii libcrmcluster11.1.7-1
ii libcrmcommon2 1.1.7-1
ii libesmtp6 1.0.6-1+b1
ii libglib2.0-0 2.33.12+really2.32.4-5
ii libgnutls26 2.12.20-7
ii liblrm2 1.0.9+hg2665-1
ii libltdl7 2.4.2-1.1
ii libncurses5 5.9-10
ii libpam0g 1.1.3-7.1
ii libpe-rules2 1.1.7-1
ii libpe-status3 1.1.7-1
ii libpengine3 1.1.7-1
ii libpils2 1.0.9+hg2665-1
ii libplumb2 1.0.9+hg2665-1
ii libsnmp15 5.4.3~dfsg-2.7
ii libssl1.0.0 1.0.1e-2+deb7u4
ii libstonithd1 1.1.7-1
ii libtinfo5 5.9-10
ii libtransitioner1 1.1.7-1
ii libuuid1 2.20.1-5.3
ii libxml2 2.8.0+dfsg1-7+nmu2
ii libxslt1.11.1.26-14.1
ii python2.7.3-4+deb7u1
ii python2.6 2.6.8-1.1
ii python2.7 2.7.3-6
ii resource-agents 1:3.9.2-5+deb7u1
pacemaker recommends no packages.
pacemaker suggests no packages.
-- Configuration Files:
/etc/init.d/pacemaker changed [not included]
-- 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#588431: (no subject)
> That is sad that iirc we do not have in fail2ban an easy ability to extend list of failregex's in additional file like /etc/fail2ban/filter.d/sshd.local so you didn't have to 'merge' for every upgrade. Feel free to file a wishlist bug, who knows... ;-) No, but at least now we can use a failregex in a jail.local definition. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735851: mydumper creates table mysql.mydumperdummy causing galera problems
Package: mydumper Version: 0.5.2-1 Upstream bug and patch that has been accepted. https://bugs.launchpad.net/mydumper/+bug/1267501 Given it was introduced a long time ago: http://bazaar.launchpad.net/~perconardba/mydumper/0.6/revision/23 It will affect all versions of mydumper Also mydumper-0.6 has some nice features if a version bump can be considered. -- Daniel Black, Engineer @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#410077:
To be fixed in 0.9 release https://github.com/fail2ban/fail2ban/commit/d07df6637071b7ffa8be988a834a6bb71d9bf932 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620364:
https://github.com/fail2ban/fail2ban/commit/224e795f4c45fc9cf4b8c769b1fa97d544aeacde for 0.8.12 release -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711465:
patch created by ksmadsen in http://munin-monitoring.org/ticket/1275 The description provided was: I've traced this problem to the fact that on the RH kernel we are using, the rd_ticks/wr_ticks in /sys/block/*/stat are 32-bit numbers, so when the ticks wraps, a negative value is reported. Looking at the kernel source code, the tick counters are internally all 64-bit, but when they are read from the stat file, the output is limited to 32-bits. The patch: https://github.com/openquery/munin/commit/91a9e62b14957cabcd8fcfceeb6f656b95eb2261 I'm going to do a pull request to upstream soon. For the 2.0.6 the last chunk doesn't apply as this was upstream's "fix". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720275: munin-plugins-core: crontab for apt and apt_all plugins missing MUNIN_PLUGSTATE=/var/lib/munin-node/plugin-state/root
Package: munin-plugins-core Version: 2.0.6-4+deb7u1 Severity: normal Tags: patch Dear Maintainer, The created /etc/cron.d/munin-node doesn't work as when the plugins are run from cron they don't know the state directory Adding the following to this cron file fixed it for me: MUNIN_PLUGSTATE=/var/lib/munin-node/plugin-state/root -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.9.3-x86_64-linode33 (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 munin-plugins-core depends on: ii munin-common 2.0.6-4+deb7u1 ii perl 5.14.2-21 Versions of packages munin-plugins-core recommends: ii libnet-snmp-perl 6.0.1-2 Versions of packages munin-plugins-core suggests: pn libnet-netmask-perl pn libnet-telnet-perl ii python2.7.3-4 ii ruby 1:1.9.3 ii ruby1.8 [ruby-interpreter]1.8.7.358-7 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1 -- 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#720280: munin-async init script, missing status, has wrong name, doesn't remove pid
Package: munin-async
Version: 2.0.6-4+deb7u1
Severity: normal
Tags: patch
Dear Maintainer,
I needed a status to run this init under puppet without continious restarts.
While adding this (copied from munin-node) I noticed the pid file wasn't remove
on stop
and the the SCRIPTNAME was wrong.
-- System Information:
Debian Release: 7.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.9.3-x86_64-linode33 (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 munin-async depends on:
ii adduser 3.113+nmu3
ii munin-common 2.0.6-4+deb7u1
ii munin-node2.0.6-4+deb7u1
ii perl 5.14.2-21
ii perl-modules 5.14.2-21
munin-async recommends no packages.
munin-async suggests no packages.
-- Configuration Files:
/etc/init.d/munin-async changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Munin asynchronous server"
NAME=munin-asyncd
DAEMON=/usr/share/munin/$NAME
DAEMON_ARGS=""
DAEMON_USER="munin-async"
PIDFILE=/var/run/munin/$NAME.pid
SCRIPTNAME=/etc/init.d/munin-async
[ -x "$DAEMON" ] || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
. /lib/init/vars.sh
. /lib/lsb/init-functions
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --background --make-pidfile --pidfile
$PIDFILE --chuid $DAEMON_USER --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --background --make-pidfile --pidfile
$PIDFILE --chuid $DAEMON_USER --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
}
do_stop()
{
# killproc() doesn't try hard enough if the pid file is missing,
# so create it is gone and the daemon is still running
if [ ! -r $PIDFILE ]; then
pid=$(pidofproc -p $PIDFILE $DAEMON)
if [ -z "$pid" ]; then
[ "$VERBOSE" != no ] && log_progress_msg "stopped
beforehand"
log_end_msg 0
return 0
fi
echo $pid 2>/dev/null > $PIDFILE
if [ $? -ne 0 ]; then
log_end_msg 1
return 1
fi
fi
killproc -p $PIDFILE /usr/bin/munin-node
ret=$?
# killproc() isn't thorough enough, ensure the daemon has been
# stopped manually
attempts=0
until ! pidofproc -p $PIDFILE $DAEMON >/dev/null; do
attempts=$(( $attempts + 1 ))
sleep 0.05
[ $attempts -lt 20 ] && continue
log_end_msg 1
return 1
done
rm "$PIDFILE"
[ $ret -eq 0 ] && [ "$VERBOSE" != no ] && log_progress_msg "done"
log_end_msg $ret
return $ret
}
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --background --make-pidfile --quiet
--pidfile $PIDFILE --exec $DAEMON
return 0
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave 'force-reload' as an alias for 'restart'.
#
#log_daemon_msg "Reloading $DESC" "$NAME"
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
status)
pid=$(pidofproc -p $PIDFILE $DAEMON)
ret=$?
pid=${pid% } # pidofproc() supplies a trailing space, strip it
if [ $ret -eq 0 ]; then
log_success_msg "Munin-Async is running (PID: $pi
Bug#711465: pull request
The pull request to upstream: https://github.com/munin-monitoring/munin/pull/126 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711465:
control: +patch to remove the negative numbers the patch previously mentioned does work and was accepted upstream: https://github.com/munin-monitoring/munin/pull/126 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707328:
Few init script changes required: in do_start - there is no --test argument. not sure why --make-pidfile is there, lsyncd creates its own pid file (but still doesn't remove it - (https://github.com/axkibe/lsyncd/issues/196) Hope pages and doco should refer to github and its wiki as it seems the code.google.com is out of date in some aspects. A nice priority would be good as the initial start is quite a high CPU, ram, IO load. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757421: selinux-basics: selinux-activate doesn't install kernel args on extlinux
Package: selinux-basics Version: 0.5.2 Severity: wishlist Dear Maintainer, * What led up to the situation? I started a freedombox using freedombox maker which uses vmdebootstrap to create and image. The VM has extlinux as the bootloader. I followed the selinux steps on wiki.debian.org/SELinux/Setup. After rebooting no selinux was enabled. * What exactly did you do (or not do) that was effective (or ineffective)? I discovered that the /extlinux.conf boot line didn't contain the selinux kernel arguements like /etc/default/grub.conf. * What was the outcome of this action? Adding these made selinux work. * What outcome did you expect instead? Selinux enabled. /extlinux.conf: default linux timeout 1 label linux kernel boot/vmlinuz-3.14-2-486 append initrd=boot/initrd.img-3.14-2-486 root=UUID=5cb2f0d4-21b6-43b2-9f0b-ef908696a4ac ro selinux=1 security=selinux -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-2-486 Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages selinux-basics depends on: ii checkpolicy 2.3-1 ii policycoreutils 2.3-1 pn python:any ii selinux-utils2.3-1 Versions of packages selinux-basics recommends: ii selinux-policy-default 2:2.20140421-4 ii setools 3.3.8-3 Versions of packages selinux-basics suggests: pn logcheck pn syslog-summary -- 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#742267: patches
tags 742267 patch
Two patches as suggested by Petter (which I have a preference too):
vmdebootstrap-vmlinuz-nonversioned.patch - for non-versioned /vmlinux boot
vmdebootstrap-etc-extlinux.patch for placing etclinux.conf in /etc
directory and to put a symlink there (if the filesystem supports this)
The alternative to the vmlinuz-nonversioned patch is a
/etc/kernel/postinst.d/update-extlinux hook like attached to update the
extlinux.conf. The name has to be further alphabetical than initramfs
because the script checks it was created before updateing extlinux.conf
--- /usr/sbin/vmdebootstrap.orig 2014-08-08 11:26:26.612391333 +1000
+++ /usr/sbin/vmdebootstrap 2014-08-08 11:31:56.596325797 +1000
@@ -410,18 +410,6 @@
def install_extlinux(self, rootdev, rootdir):
self.message('Installing extlinux')
-def find(pattern):
-dirname = os.path.join(rootdir, 'boot')
-basenames = os.listdir(dirname)
-logging.debug('find: %s' % basenames)
-for basename in basenames:
-if re.search(pattern, basename):
-return os.path.join('boot', basename)
-raise cliapp.AppException('Cannot find match: %s' % pattern)
-
-kernel_image = find('vmlinuz-.*')
-initrd_image = find('initrd.img-.*')
-
out = self.runcmd(['blkid', '-c', '/dev/null', '-o', 'value',
'-s', 'UUID', rootdev])
uuid = out.splitlines()[0].strip()
@@ -438,8 +426,8 @@
append initrd=%(initrd)s root=UUID=%(uuid)s ro %(kserial)s
%(extserial)s
''' % {
-'kernel': kernel_image,
-'initrd': initrd_image,
+'kernel': 'vmlinuz',
+'initrd': 'initrd',
'uuid': uuid,
'kserial':
'console=ttyS0,115200' if self.settings['serial-console'] else '',
--- /tmp/vmdebootstrap 2014-08-08 11:50:59.126985327 +1000
+++ /usr/sbin/vmdebootstrap 2014-08-08 12:05:27.218098768 +1000
@@ -415,6 +415,14 @@
uuid = out.splitlines()[0].strip()
conf = os.path.join(rootdir, 'extlinux.conf')
+confreal = os.path.join(rootdir, 'etc', 'extlinux.conf')
+try:
+conflink = os.join('etc', 'extlinux.conf')
+os.symlink(conflink, conf)
+conf = confreal
+except OSError, e:
+logging.debug('symlink %s -> %s unsupported %s' % (conflink, conf, e))
+pass
logging.debug('configure extlinux %s' % conf)
f = open(conf, 'w')
f.write('''
#!/bin/sh
# Needs to run after initramfs-tools as we want to make sure that
# exists before changing extlinux.conf
version=$1
kernel=$2
if [ -f /etc/extlinux.conf ]
then
extlinux=/etc/extlinux.conf
elif [ -f /extlinux.conf ]
then
extlinux=/extlinux.conf
else
exit
fi
if [ -f "${kernel}" ]
then
sed -i -e "s|^kernel .*|kernel ${kernel}|" "${extlinux}"
fi
bootpath=${kernel%/*}
initramfs=${bootpath}/initrd.img-${version}
if [ -f "${initramfs}" ]
then
sed -i -e "s|^\\(append .*\\)initrd=[^
]*\\(.*\\)|\\1initrd=${initramfs}\\2|" "${extlinux}"
fi
Bug#707328: fyi lsyncd-2.1.4 is packagable with same patches as 2.0.7
Package: lsyncd
Version: 2.1.4-1
Severity: wishlist
There's a small bit of fuzz correction needed with the patch however the rest
of the build works.
The trickest thing is the user configation file options have changed for rsync.
In 2.0.7 the following configuration worked and it doesn't in 2.1.4
sync{default.rsyncssh,
source="/var/www",
host="to",
targetdir="/var/www",
rsyncOpts={"--bwlimit=5","-lAXsptgoD"},
}
Now the compatible option is of the form:
https://github.com/axkibe/lsyncd/wiki/Lsyncd%202.1.x%20%E2%80%96%20Layer%204%20Config%20%E2%80%96%20Default%20Behavior
sync{default.rsyncssh,
source="/var/www",
host="to",
targetdir="/var/www",
delete="running",
rsync = {
_extra = { "--bwlimit=5000"},
xattr = true,
links = true,
}
}
-- System Information:
Debian Release: 6.0.7
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.8.4-x86_64-linode31 (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 lsyncd depends on:
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro
ii lua5.15.1.4-5Simple, extensible, embeddable pro
ii rsync 3.0.7-2fast remote file copy program (lik
lsyncd recommends no packages.
lsyncd 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#410364: wireshark security vulnerability - 0.99.5 released
Package: wireshark Version: 0.99.5 http://www.wireshark.org/security/wnpa-sec-2007-01.html Wireshark 0.99.5 fixes the following vulnerabilities: The TCP dissector could hang or crash while reassembling HTTP packets. (Bug 1200) Versions affected: 0.99.2 to 0.99.4 CVE-2007-0459 The HTTP dissector could crash. Versions affected: 0.99.3 to 0.99.4 CVE-2007-0458 On some systems, the IEEE 802.11 dissector could crash. Versions affected: 0.10.14 to 0.99.4 CVE-2007-0457 On some systems, the LLT dissector could crash. Versions affected: 0.99.3 to 0.99.4 CVE-2007-0456 Watch out for a gcc-3 compile error https://bugs.gentoo.org/show_bug.cgi?id=165340 FreeBSD may have some patches - investigating now - will report in above url -- Daniel Black <[EMAIL PROTECTED]> Gentoo Foundation pgpMQcSbIXZeT.pgp Description: PGP signature
Bug#410364: gcc-3 compatibility
Severity: critical Tags: security Patches needed for gcc-3 compatibility 1. http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/wireshark/files/wireshark-except-double-free.diff?rev=1.1&view=log reference: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1001 http://bugs.gentoo.org/show_bug.cgi?id=133092 http://bugs.gentoo.org/show_bug.cgi?id=145974 2. http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/wireshark/files/patch-epan_dissectors_packet-diameter.c -- Daniel Black <[EMAIL PROTECTED]> Gentoo Foundation pgpVUhVMQuX8p.pgp Description: PGP signature
Bug#1006531:
Thought my last comment was obvious, but here's it more explicitly: requires https://github.com/MariaDB/server/pull/2893 as debian explicit architectures aren't neede since dh_auto_configure handles this. If it works, upstream welcome. Hurd string from uname -m, "SYSTEM processor: i686-AT386" in mariadb output. And wiki reference https://en.wikipedia.org/wiki/Uname diff --git a/cmake/build_configurations/mysql_release.cmake b/cmake/build_configurations/mysql_release.cmake index 961db1b13b0..e8431ca831f 100644 --- a/cmake/build_configurations/mysql_release.cmake +++ b/cmake/build_configurations/mysql_release.cmake @@ -118,7 +118,10 @@ ELSEIF(DEB) SET(WITH_ZLIB system CACHE STRING "") SET(WITH_LIBWRAP ON) SET(HAVE_EMBEDDED_PRIVILEGE_CONTROL ON) - SET(PLUGIN_AUTH_SOCKET YES CACHE STRING "") + # No hurd implementation + IF(NOT CMAKE_SYSTEM_PROCESSOR STREQUAL "i686-AT386") +SET(PLUGIN_AUTH_SOCKET YES CACHE STRING "") + ENDIF() SET(WITH_EMBEDDED_SERVER ON CACHE BOOL "") SET(WITH_PCRE system CACHE STRING "") SET(CLIENT_PLUGIN_ZSTD OFF)
Bug#1060056:
merged - https://github.com/MariaDB/server/pull/2995
Bug#1063739: Bug#1006531: mariadb: FTBFS on hurd-i386: cmake/plugin.cmake: Plugin AUTH_SOCKET cannot be built
Fixed by https://github.com/MariaDB/server/pull/3002 which didn't make the release unfortunately. On Mon, 12 Feb 2024 at 09:43, Otto Kekäläinen wrote: > > Version: 1:10.11.7-1 > > I confirm this was fixed in latest upload MariaDB 1:10.11.7-1, which > included > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/66 > > Unfortunately there seems to be more failures now that build is > passing on this one, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063739.
Bug#1063739: Bug#1006531: mariadb: FTBFS on hurd-i386: cmake/plugin.cmake: Plugin AUTH_SOCKET cannot be built
Opps, wrong one - this one https://github.com/MariaDB/server/pull/3039 On Mon, 12 Feb 2024 at 10:10, Daniel Black wrote: > > Fixed by https://github.com/MariaDB/server/pull/3002 which didn't make > the release unfortunately. > > On Mon, 12 Feb 2024 at 09:43, Otto Kekäläinen wrote: > > > > Version: 1:10.11.7-1 > > > > I confirm this was fixed in latest upload MariaDB 1:10.11.7-1, which > > included > > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/66 > > > > Unfortunately there seems to be more failures now that build is > > passing on this one, see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063739.
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
./sql/ha_partition.cc:5657 is coping over a blob of memory. Could it just be slow? Does running main.partition on its own generate the same result? Alternately one of the loop constructs around it got some incorrect values. Examine local variables (info locals) around what was executing on timeout. Also look at the variable constructs from which they were calculated. Possibly in multiple threads. mtr --gdb='b handle_fatal_signal; r' The thread that receives the timeout signal from mtr isn't necessarily the one being slow. Is failure repeatable with a lower number of mtr --parallel? On Sat, 6 Jul 2024 at 11:42, Otto Kekäläinen wrote: > > I built the binary in debug mode and that yielded a stacktrace: > > *** > > main.partition w38 [ retry-fail ] > Test ended at 2024-07-06 01:14:43 > > CURRENT_TEST: main.partition > mysqltest: At line 3010: query 'select id from t1 where data = 'ab' > order by id' failed: (2013): Lost connection to server > during query > > The result from queries just before the failure was: > < snip > > insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, > 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; > select id from t1 where data = 'ab' order by id; > id > 4 > 5 > 6 > 14 > 15 > 16 > drop table t1; > create table t1(id int unsigned not null, > data text default null, > key data_idx (data(1),id) > ) default charset=utf8 > partition by range (id) ( > partition p10 values less than (10), > partition p20 values less than (20) > ); > insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, > 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; > select id from t1 where data = 'ab' order by id; > > More results from queries before failure can be found in > /home/otto/mariadb-server/builddir/mysql-test/var/38/log/partition.log > > - found 'core' (1/1) > worker[38] > Restart - not started > Core generated by '/home/otto/mariadb-server/builddir/sql/mariadbd' > Output from gdb follows. The first stack trace is from the failing thread. > The following stack traces are from all threads (so the failing one is > duplicated). > -- > [New LWP 3175949] > [New LWP 3175830] > [New LWP 3175886] > [New LWP 3175896] > [New LWP 3175931] > [New LWP 3175902] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". > Core was generated by `/home/otto/mariadb-server/builddir/sql/mariadbd > --defaults-group-suffix=.1 --de'. > Program terminated with signal SIGUSR1, User defined signal 1. > #0 0xfff80001028928c0 in __pthread_kill_implementation > (threadid=1892278236620992, signo=10, no_tid=0) at > ./nptl/pthread_kill.c:43 > 43 ./nptl/pthread_kill.c: No such file or directory. > [Current thread is 1 (Thread 0xfff8000102baa8c0 (LWP 3175949))] > #0 0xfff80001028928c0 in __pthread_kill_implementation > (threadid=1892278236620992, signo=10, no_tid=0) at > ./nptl/pthread_kill.c:43 > #1 0x01000154ca3c in my_write_core (sig=10) at ./mysys/stacktrace.c:424 > #2 0x01c39778 in handle_fatal_signal (sig=10) at > ./sql/signal_handler.cc:357 > #3 > #4 0x01f35cac in ha_partition::init_record_priority_queue > (this=0xfff800011cca7c10) at ./sql/ha_partition.cc:5657 > #5 0x01f363b4 in ha_partition::index_init > (this=0xfff800011cca7c10, inx=0, sorted=true) at > ./sql/ha_partition.cc:5762 > #6 0x01939870 in handler::ha_index_init (sorted=true, idx=0, > this=0xfff800011cca7c10) at ./sql/handler.h:3495 > #7 join_read_always_key (tab=0xfff800011cd285c0) at ./sql/sql_select.cc:24407 > #8 0x0191df74 in sub_select (join=0xfff800011c017560, > join_tab=0xfff800011cd285c0, end_of_records=) at > ./sql/sql_select.cc:23632 > #9 0x0195c6ec in do_select (procedure=0x0, > join=0xfff800011c017560) at ./sql/sql_select.cc:23146 > #10 JOIN::exec_inner (this=0xfff800011c017560) at ./sql/sql_select.cc:5010 > #11 0x0195cd60 in JOIN::exec (this=0xfff800011c017560) at > ./sql/sql_select.cc:4796 > #12 0x0195a938 in mysql_select (thd=0xfff800011c000dc8, > tables=0xfff800011c015f48, fields=..., conds=0xfff800011c016818, > og_num=1, order=, group=, > having=, proc_param=, > select_options=, result=, > unit=, select_lex=) at > ./sql/sql_select.cc:5326 > #13 0x0195ac54 in handle_select (thd=0xfff800011c000dc8, > lex=0xfff800011c005170, result=0xfff800011c017538, > setup_tables_done_option=) at ./sql/sql_select.cc:628 > #14 0x018a0d64 in execute_sqlcom_select > (thd=0xfff800011c000dc8, all_tables=0xfff800011c015f48) at > ./sql/sql_parse.cc:6141 > #15 0x018aea04 in mysql_execute_command > (thd=0xfff800011c000dc8, is_called_from_prepared_stmt=false) at > ./sql/sql_parse.cc:3950 > #16 0x018b6168 in mysql_parse (thd=0xfff800011c000dc8, > rawbuf=, length=, > parser_state=) at ./sql/sql_parse.cc:7862 > #17 0x018b929c in dispatch_command (command=COM_QUERY, > thd=
