Bug#544013: mysql-server-5.1: logrotate script cannot handle stopped mysqld
Turns out the patch I submitted didn't fix the issue. Sorry about that. Please ignore the patch in my previous email. On Wed, Jul 15, 2020 at 11:08 PM Francesc Zacarias wrote: > Hi! > > I'm experiencing the same issue as described in this bug with debian sid > and mysql-server-5.7 (5.7.26-1+b1). I noticed that one out of three times > my system boots, logrotate service fails with the following error: > > ``` > Jul 09 07:12:01 baal systemd[1]: Starting Rotate log files... > Jul 09 07:12:01 baal logrotate[851]: error: error running shared > postrotate script for '/var/log/mysql.log /var/log/mysql/*log> > Jul 09 07:12:01 baal systemd[1]: logrotate.service: Main process exited, > code=exited, status=1/FAILURE > Jul 09 07:12:01 baal systemd[1]: logrotate.service: Failed with result > 'exit-code'. > Jul 09 07:12:01 baal systemd[1]: Failed to start Rotate log files. > ``` > > Looking at journalctl, I can see that every time this issue occurs, mysqld > is started and logrotate fails *at the same time*: > > ``` > Jul 09 07:12:01 baal mysqld[847]: 2020-07-09T06:12:01.283924Z 0 [Note] > /usr/sbin/mysqld: ready for connections. > Jul 09 07:12:01 baal mysqld[847]: Version: '5.7.26-1+b1' socket: > '/var/run/mysqld/mysqld.sock' port: 3306 (Debian) > ... > Jul 09 07:12:01 baal systemd[1]: logrotate.service: Main process exited, > code=exited, status=1/FAILURE > Jul 09 07:12:01 baal systemd[1]: logrotate.service: Failed with result > 'exit-code'. > ``` > > This and the fact that the issue does not reproduce every time makes me > suspect that is a race-condition between logrotate and mysqld. Looking at > the code in /etc/logrotate.d/mysql-server it seems like logrotate first > checks if mysql is running before issuing the "mysqladmin flush-logs" > command. That check is done by issuing "mysqladmin ping" (this also checks > that /etc/mysql/debian.cnf is valid). If this check fails, then it will try > to verify if the mysql process exists. If it does, then it will fail with > an exit code = 1, which causes the error messages in my logs above. > I'm sure you already noticed the issue here: what if mysqld has not > started yet by the time "mysqladmin ping" runs, but it's up right by the > time killall is executed? Apparently, this happens quite often in my system. > > To fix this, I suggest reverting the checks: first validate that mysqld is > running. If not, then there is no reason to issue "mysqladmin flush-logs" > and the script can finish successfully. If mysqld is running *and* > "mysqladmin ping" fails, then it should definitely throw an error. > > This approach is not completely free of race-conditions either, but it > should be more rare. I'm attaching a patch with the solution I just > described. I've had this patch applied to my system for a week and the > issue has not been reproduced since. The *best* solution would be to simply > attempt to apply "flush-logs" and react differently depending on the exit > code. Unfortunately, it seems like mysqladmin does not return different > exit codes on different errors (in my tests it always returns 1), so this > approach is not possible at the moment. > > Please, apply this patch and fix this issue! > > Kind regards, > Francesc > > >
Bug#544013: mysql-server-5.1: logrotate script cannot handle stopped mysqld
Hi! I'm experiencing the same issue as described in this bug with debian sid and mysql-server-5.7 (5.7.26-1+b1). I noticed that one out of three times my system boots, logrotate service fails with the following error: ``` Jul 09 07:12:01 baal systemd[1]: Starting Rotate log files... Jul 09 07:12:01 baal logrotate[851]: error: error running shared postrotate script for '/var/log/mysql.log /var/log/mysql/*log> Jul 09 07:12:01 baal systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE Jul 09 07:12:01 baal systemd[1]: logrotate.service: Failed with result 'exit-code'. Jul 09 07:12:01 baal systemd[1]: Failed to start Rotate log files. ``` Looking at journalctl, I can see that every time this issue occurs, mysqld is started and logrotate fails *at the same time*: ``` Jul 09 07:12:01 baal mysqld[847]: 2020-07-09T06:12:01.283924Z 0 [Note] /usr/sbin/mysqld: ready for connections. Jul 09 07:12:01 baal mysqld[847]: Version: '5.7.26-1+b1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian) ... Jul 09 07:12:01 baal systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE Jul 09 07:12:01 baal systemd[1]: logrotate.service: Failed with result 'exit-code'. ``` This and the fact that the issue does not reproduce every time makes me suspect that is a race-condition between logrotate and mysqld. Looking at the code in /etc/logrotate.d/mysql-server it seems like logrotate first checks if mysql is running before issuing the "mysqladmin flush-logs" command. That check is done by issuing "mysqladmin ping" (this also checks that /etc/mysql/debian.cnf is valid). If this check fails, then it will try to verify if the mysql process exists. If it does, then it will fail with an exit code = 1, which causes the error messages in my logs above. I'm sure you already noticed the issue here: what if mysqld has not started yet by the time "mysqladmin ping" runs, but it's up right by the time killall is executed? Apparently, this happens quite often in my system. To fix this, I suggest reverting the checks: first validate that mysqld is running. If not, then there is no reason to issue "mysqladmin flush-logs" and the script can finish successfully. If mysqld is running *and* "mysqladmin ping" fails, then it should definitely throw an error. This approach is not completely free of race-conditions either, but it should be more rare. I'm attaching a patch with the solution I just described. I've had this patch applied to my system for a week and the issue has not been reproduced since. The *best* solution would be to simply attempt to apply "flush-logs" and react differently depending on the exit code. Unfortunately, it seems like mysqladmin does not return different exit codes on different errors (in my tests it always returns 1), so this approach is not possible at the moment. Please, apply this patch and fix this issue! Kind regards, Francesc --- mysql-server 2019-06-14 16:19:35.0 +0100 +++ /etc/logrotate.d/mysql-server 2020-07-09 07:49:37.853383663 +0100 @@ -11,15 +11,14 @@ sharedscripts postrotate test -x /usr/bin/mysqladmin || exit 0 + killall -q -s0 -umysql mysqld || exit 0 # If this fails, check debian.conf! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then # Really no mysqld or rather a missing debian-sys-maint user? # If this occurs and is not a error please report a bug. #if ps cax | grep -q mysqld; then - if killall -q -s0 -umysql mysqld; then - exit 1 - fi + exit 1 else $MYADMIN flush-logs fi
Bug#825317:
I'm currently running debian sid with bash-completion package version 1:2.7-1 and I'm still experiencing this issue. Note that this was fixed in Ubuntu more than 2 years ago. https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061 I applied the patch manually on my laptop and it addresses the problem. Any chance you could merge this patch soon?
Bug#837130: vim package cannot be installed because of missing dependency
Source: vim Version: 2:7.4.2330-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * I upgraded my packages via apt-get update/dist-upgrade as usual. vim got uninstalled because a new vim package was released but one of its dependencies could not be installed due to not being available in the repos: vim-runtime (= 2:7.4.2330-1). * What exactly did you do (or not do) that was effective (or ineffective)? * - * What was the outcome of this action? * vim does not exist on my system anymore, which is a tool I use constantly. * What outcome did you expect instead? * I expected a newer version of vim to be installed, not to be removed :) *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-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 Init: systemd (via /run/systemd/system)
Bug#770090: systemd: systemctl poweroff doesn't poweroff
After upgrading to systemd 215-18, I have not been able to reproduce the issue again. Finally, my computer powers off and reboots properly again. I only wish that systemd had more verbose debugging messages to understand what was going on. Cheers, Francesc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770090: Info received (Bug#770090: systemd: systemctl poweroff doesn't poweroff)
On 03/01/2015 04:36 PM, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian systemd Maintainers pkg-systemd-maintain...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 770...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. I recently migrated to Debian Sid. Problem still persists (systemd v215-17). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776395: java-package: Does not use the system's keystore
Then it's fine. No hurries. Good luck with the Jessie release! Cheers! Francesc On 23 February 2015 at 16:00, Emmanuel Bourg ebo...@apache.org wrote: Le 23/02/2015 15:43, Francesc Zacarias a écrit : Hi! It's been nearly a month and the patch does not seem to applied to experimental or unstable yet. Is there a problem? There is no problem, I'm just busy on other things and since we are still under the Jessie freeze I haven't rushed to upload it. If you need this quickly I can upload it to experimental though. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776395: java-package: Does not use the system's keystore
Hi! It's been nearly a month and the patch does not seem to applied to experimental or unstable yet. Is there a problem? KInd regards, Francesc On 29 January 2015 at 16:10, Emmanuel Bourg ebo...@apache.org wrote: This looks excellent, thank you very much. I'll merge it in the next upload. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776395: java-package: Does not use the system's keystore
Hi Emmanuel,
Good point! I'm attaching a new patch adding a switch to enable or
disable this feature. The default is disabled, so the script will work
as before unless explicitly stated.
Please, tell me if I need to do something else to get this merged.
Cheers!
Francesc
On 28 January 2015 at 00:07, Emmanuel Bourg ebo...@apache.org wrote:
Hi Francesc,
Thank you for the patch, this is an interesting suggestion. I wonder if
we should really go that far with the system integration of the
generated package though. I can imagine that someone may want to install
a stock Oracle JRE with no Debian interferences. So maybe this
integration could be enabled optionally with a
--with-system-certificates parameter on the command line.
Emmanuel Bourg
From de83ea689caf8bc072155d3da57ed06f78127a40 Mon Sep 17 00:00:00 2001
From: Francesc Zacarias franc...@spotify.com
Date: Tue, 27 Jan 2015 17:07:43 +0100
Subject: [PATCH] Add option to integrate with the system's keystore
---
lib/javase.sh | 10 +-
lib/jdk.sh| 3 +++
lib/jre.sh| 5 -
make-jpkg | 17 ++---
make-jpkg.1 | 5 +
5 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/lib/javase.sh b/lib/javase.sh
index 3e539b3..9bfd3ec 100644
--- a/lib/javase.sh
+++ b/lib/javase.sh
@@ -126,8 +126,16 @@ if [ \$1 = configure ]; then
update-alternatives --install \$link_path/\$link_name \$plugin_name \$plugin $j2se_priority
fi
}
-
EOF
+if [ $create_cert_softlinks == true ];then
+cat $debian_dir/postinst EOF
+for subdir in lib/security jre/lib/security;do
+if [ -f $jvm_base$j2se_name/\$subdir/cacerts ]; then
+ln -sf /etc/ssl/certs/java/cacerts $jvm_base$j2se_name/\$subdir/cacerts
+fi
+done
+EOF
+fi
eval $j2se_install $debian_dir/postinst
cat $debian_dir/postinst EOF
diff --git a/lib/jdk.sh b/lib/jdk.sh
index 1c75876..46dec6f 100644
--- a/lib/jdk.sh
+++ b/lib/jdk.sh
@@ -13,6 +13,9 @@ j2sdk_control() {
# No browser on ARM yet
java_browser_plugin=
fi
+if [ $create_cert_softlinks == true ]; then
+depends=$depends, ca-certificates-java
+fi
for i in `seq 5 ${j2se_release}`;
do
provides_runtime=${provides_runtime} java${i}-runtime,
diff --git a/lib/jre.sh b/lib/jre.sh
index 93aed8b..7b339d8 100644
--- a/lib/jre.sh
+++ b/lib/jre.sh
@@ -1,6 +1,9 @@
j2re_control() {
j2se_control
+if [ $create_cert_softlinks == true ]; then
+depends=ca-certificates-java
+fi
for i in `seq 5 ${j2se_release}`;
do
provides_runtime=${provides_runtime} java${i}-runtime,
@@ -9,7 +12,7 @@ j2re_control() {
cat EOF
Package: $j2se_package
Architecture: any
-Depends: \${misc:Depends}, \${shlibs:Depends}
+Depends: \${misc:Depends}, \${shlibs:Depends}, $depends
Recommends: netbase
Provides: java-virtual-machine, java-runtime, java2-runtime, $provides_runtime java-runtime-headless, java2-runtime-headless, $provides_headless java-browser-plugin
Description: $j2se_title
diff --git a/make-jpkg b/make-jpkg
index a90c26e..6e53003 100755
--- a/make-jpkg
+++ b/make-jpkg
@@ -79,14 +79,15 @@ Supported java binary distributions currently include:
The following options are recognized:
- --full-name NAME full name used in the maintainer field of the package
- --email EMAIL email address used in the maintainer field of the package
- --changes create a .changes file
- --revision add debian revision
- --source build a source package instead of a binary deb package
+ --full-name NAME full name used in the maintainer field of the package
+ --email EMAILemail address used in the maintainer field of the package
+ --changescreate a .changes file
+ --revision add debian revision
+ --source build a source package instead of a binary deb package
+ --with-system-certs integrate with the system's keystore
- --help display this help and exit
- --version output version information and exit
+ --help display this help and exit
+ --versionoutput version information and exit
EOF
}
@@ -131,6 +132,8 @@ while [[ $# -gt 0 x$1 == x--* ]]; do
genchanges=true
elif [[ x$1 == x--source ]]; then
build_source=true
+elif [[ x$1 == x--with-system-certs ]]; then
+create_cert_softlinks=true
else
unrecognized_option $1
fi
diff --git a/make-jpkg.1 b/make-jpkg.1
index bceec92..ba1d000 100644
--- a/make-jpkg.1
+++ b/make-jpkg.1
@@ -52,6 +52,11 @@ add debian revision
.B --source
build a source package instead of a binary deb package
.TP
+.B --with-system-certs
+Replace the JVMs keystore with a softlink to the system's keystore,
+(/etc/ssl/certs/java/cacerts) which is managed automatically by the
+ca-certificates and ca-certificates-java packages.
+.TP
.B --help
display help text and exit
.TP
--
2.1.4
Bug#776395: java-package: Does not use the system's keystore
Package: java-package
Version: 0.56
Severity: important
Tags: patch
Dear Maintainer,
JVMs supported by Debian create a symlink for the keystore in
$JAVA_HOME/lib/security/cacerts pointing to /etc/ssl/certs/java/cacerts.
This, together with package ca-certificates-java, unifies the
management of the keystore of all Debian JVMs very nicely.
Packages generated with java-package do not create that symlink and
do not depend on ca-certificates-java which means that the standard
process to install SSL certificates (see
/usr/share/doc/ca-certificates/README.Debian) is broken.
The attached patch fixes this issue.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-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
Init: systemd (via /run/systemd/system)
Versions of packages java-package depends on:
ii debhelper 9.20141022
ii dpkg-dev1.17.23
ii fakeroot1.20.2-1
ii libasound2 1.0.28-1
ii libx11-62:1.6.2-3
ii unzip 6.0-14
Versions of packages java-package recommends:
ii gcc 4:4.9.1-5
Versions of packages java-package suggests:
ii openjdk-7-jre 7u71-2.5.3-2
-- no debconf information
From 31ae773023ded5aa6e7d20bc2b63a33ab20d48b9 Mon Sep 17 00:00:00 2001
From: Francesc Zacarias franc...@spotify.com
Date: Tue, 27 Jan 2015 17:07:43 +0100
Subject: [PATCH] Unify cacerts
---
lib/jdk.sh| 2 +-
lib/jre.sh| 2 +-
lib/oracle-jdk.sh | 2 ++
lib/oracle-jre.sh | 2 ++
4 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/jdk.sh b/lib/jdk.sh
index 1c75876..45ebb30 100644
--- a/lib/jdk.sh
+++ b/lib/jdk.sh
@@ -22,7 +22,7 @@ j2sdk_control() {
cat EOF
Package: $j2se_package
Architecture: any
-Depends: \${misc:Depends}, $depends
+Depends: \${misc:Depends}, $depends, ca-certificates-java
Recommends: netbase
Provides: java-virtual-machine, java-runtime, java2-runtime, $provides_runtime $java_browser_plugin java-compiler, java2-compiler, java-runtime-headless, java2-runtime-headless, $provides_headless java-sdk, java2-sdk, $provides_sdk
Description: $j2se_title
diff --git a/lib/jre.sh b/lib/jre.sh
index 93aed8b..eb9a3cd 100644
--- a/lib/jre.sh
+++ b/lib/jre.sh
@@ -9,7 +9,7 @@ j2re_control() {
cat EOF
Package: $j2se_package
Architecture: any
-Depends: \${misc:Depends}, \${shlibs:Depends}
+Depends: \${misc:Depends}, \${shlibs:Depends}, ca-certificates-java
Recommends: netbase
Provides: java-virtual-machine, java-runtime, java2-runtime, $provides_runtime java-runtime-headless, java2-runtime-headless, $provides_headless java-browser-plugin
Description: $j2se_title
diff --git a/lib/oracle-jdk.sh b/lib/oracle-jdk.sh
index 1fa6657..6b3d45a 100644
--- a/lib/oracle-jdk.sh
+++ b/lib/oracle-jdk.sh
@@ -131,6 +131,8 @@ for b in $browser_plugin_dirs;do
install_browser_plugin /usr/lib/\$b/plugins libjavaplugin.so \$b-javaplugin.so \$plugin_dir/libnpjp2.so
done
fi
+
+ln -sf /etc/ssl/certs/java/cacerts $jvm_base$j2se_name/jre/lib/security/cacerts
EOF
}
diff --git a/lib/oracle-jre.sh b/lib/oracle-jre.sh
index 2e1ab8c..6941a04 100644
--- a/lib/oracle-jre.sh
+++ b/lib/oracle-jre.sh
@@ -100,6 +100,8 @@ plugin_dir=$jvm_base$j2se_name/lib/$DEB_BUILD_ARCH
for b in $browser_plugin_dirs;do
install_browser_plugin /usr/lib/\$b/plugins libjavaplugin.so \$b-javaplugin.so \$plugin_dir/libnpjp2.so
done
+
+ln -sf /etc/ssl/certs/java/cacerts $jvm_base$j2se_name/lib/security/cacerts
EOF
}
--
2.1.4
Bug#770090: systemd: systemctl poweroff doesn't poweroff
On 12/10/2014 08:59 PM, fzacarias3k . wrote:
I use poweroff.
Den 10 dec 2014 20:43 skrev Andrei POPESCU andreimpope...@gmail.com
mailto:andreimpope...@gmail.com:
On Mi, 10 dec 14, 20:11:14, fzacaria...@gmail.com
mailto:fzacaria...@gmail.com wrote:
Package: systemd
Version: 215-7
Followup-For: Bug #770090
Dear Maintainer,
I'm having a similar issue. My laptop halts, but does not
poweroff. I
have to keep the hardware power button pressed for a few seconds
for the
host to successfully poweroff. This was not the case before.
I haven't modified anything on systemd's config.
I'm running a slightly newer version than the original post but the
problem still persits.
Also, replying to the question from the last message, I don't
have any
kexec* packages installed.
Is there any other info I can provide to help?
What command are you using, 'halt' or 'poweroff'? Please mind
'halt' is
not supposed to power off your system, unless you add -p.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Sorry for the delay.
Unfortuantely, if I try to install systemd from experimental, apt will
break my laptop's setup:
The following NEW packages will be installed:
sysvinit-core{a}
The following packages will be REMOVED:
colord{a} dns-root-data{u} dnsmasq-base{u} gvfs{a} gvfs-daemons{a}
hplip{a} libmbim-glib4{u} libmbim-proxy{u} libmm-glib0{u}
libmnl0{u} libndp0{u} libnetfilter-conntrack3{u} libnm-glib-vpn1{u}
libnm-glib4{u} libnm-gtk-common{u} libnm-gtk0{u}
libnm-util2{u} libpam-systemd{a} libqmi-glib1{u} libqmi-proxy{u}
libteamdctl0{u} mobile-broadband-provider-info{u}
modemmanager{u} network-manager{a} network-manager-gnome{a}
policykit-1{a} policykit-1-gnome{a} printer-driver-postscript-hp{a}
systemd{a} systemd-sysv{a} udisks2{a}
