Logrotate failed to start in LUbuntu 20.04

Bug #1883489 reported by Viktor Mileikovskyi
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mysql-8.0 (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

After fresh installation of LUbuntu 20.04, when I switched off Plymouth, failure of logrotate appeared on the screen during boot.

(PIDs are replaced by ***)
:~$ systemctl status logrotate
● logrotate.service - Rotate log files
     Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2020-06-15 07:56:59 EEST; 32s ago
TriggeredBy: ● logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)
    Process: *** ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
   Main PID: *** (code=exited, status=1/FAILURE)

Jun 15 07:56:55 ******** systemd[***]: Starting Rotate log files...
Jun 15 07:56:59 ******** logrotate[***]: error: error running shared postrotate script for '/var/log/mysql.log /var/log/mysql/*log '
Jun 15 07:56:59 ******** systemd[***]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jun 15 07:56:59 ******** systemd[***]: logrotate.service: Failed with result 'exit-code'.
Jun 15 07:56:59 ******** systemd[***]: Failed to start Rotate log files.

I compared /etc/logrotate.d/samba with the information at https://salsa.debian.org/samba-team/samba/commit/bed29aba47558252eacfe9453d23cc1ab29770aa
Two different lines have been found:

In /etc/logrotate.d/samba:

line 6: [ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/smbd.pid ] || /usr/bin/smbcontrol smbd reload-config

line 18: [ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config

at https://...

line 6: [ ! -x /usr/bin/smbcontrol ] || [ ! -f /var/run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config

line 18: [ ! -x /usr/bin/smbcontrol ] || [ ! -f /var/run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config

There is a same difference: in LUbuntu 20.04 .pid files are searched in /run/samba/, but at https://... they are searched in /var/run/samba/. After boot, both are present and have the same PIDs.

:~$ cat /var/run/samba/nmbd.pid
abcd
:~$ cat /run/samba/nmbd.pid
abcd
:~$ cat /var/run/samba/smbd.pid
efgh
:~$ cat /run/samba/smbd.pid
efgh

(digits are replaced by letters for security reasons)

Changing the folders according to https://... and reboot solve the problem:

:~$ systemctl status logrotate
● logrotate.service - Rotate log files
     Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

After that, I tried to revert the changes and reboot. The bug cannot be reproduced anymore.

Additional information:

:~$ lsb_release -rd
Description: Ubuntu 20.04 LTS
Release: 20.04
:~$ apt-cache policy logrotate
logrotate:
  Installed: 3.14.0-4ubuntu3
  Candidate: 3.14.0-4ubuntu3
  Version Table:
 *** 3.14.0-4ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

Finally, the solution for me is:

sudo <installed text editor> /etc/logrotate.d/samba

Replace the following line (for me, line 6)

[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/smbd.pid ] || /usr/bin/smbcontrol smbd reload-config

by

[ ! -x /usr/bin/smbcontrol ] || [ ! -f /var/run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config

and the following line (for me, line 18)

[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config

by

[ ! -x /usr/bin/smbcontrol ] || [ ! -f /var/run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config

Save and reboot.

But there are two question.
Is it necessary to check both .pid files (both are present after boot), if yes, what operator should be used, || or && ?

Is it necessary to correct line 32: "elif [ -f /run/samba/samba.pid ]; then"? I did not correct it.

Because of a short time after installation, it is not tested, are the log files rotated or not.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: logrotate 3.14.0-4ubuntu3
Uname: Linux 5.6.0-18.1-liquorix-amd64 x86_64
ApportVersion: 2.20.11-0ubuntu27.2
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: LXQt
Date: Mon Jun 15 08:43:08 2020
InstallationDate: Installed on 2020-05-30 (15 days ago)
InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: logrotate
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Viktor Mileikovskyi (v-mil) wrote :
Revision history for this message
Viktor Mileikovskyi (v-mil) wrote :
Revision history for this message
Balint Harmath (bharmath) wrote :

Nice writing down of the problem. Solution is also provided. Details are also provided for the bug fixer.

Changed in logrotate (Ubuntu):
status: New → Confirmed
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "The corrected file in /etc/logrotate.d" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
affects: logrotate (Ubuntu) → samba (Ubuntu)
Revision history for this message
Viktor Mileikovskyi (v-mil) wrote :

After some weeks, logrotate failed with different error caused by MYSQL:

● logrotate.service - Rotate log files
     Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2020-06-24 08:29:59 EEST; 44s ago
TriggeredBy: ● logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)
    Process: *** ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
   Main PID: *** (code=exited, status=1/FAILURE)

Jun 24 08:29:56 ******** systemd[*]: Starting Rotate log files...
Jun 24 08:29:59 ******** logrotate[***]: error: error running shared postrotate script for '/var/log/mysql.log /var/log/mysql/*log '
Jun 24 08:29:59 ******** systemd[*]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jun 24 08:29:59 ******** systemd[*]: logrotate.service: Failed with result 'exit-code'.
Jun 24 08:29:59 ******** systemd[*]: Failed to start Rotate log files.

(Hostname and PIDs are replaced by *)

Revision history for this message
Viktor Mileikovskyi (v-mil) wrote :

This problem is related to MYSQL. The privileges of 'debian-sys-maint' user are too scanty.
The workaround is found at http://hobbymods.ru/article/linux/osibka-error-running-shared-postrotate-script-for-varlogmysqllog-varlogmysqlmysq with some changes due to the modern syntax:

1. Get the password for user 'debian-sys-maint':
  sudo grep -m 1 password /etc/mysql/debian.cnf | cut -d" " -f3
The password should be displayed. Copy it

2. Configure MySQL:
  sudo mysql --user=root mysql

2.1. In MYSQL environment set the propper password
  ALTER USER 'debian-sys-maint'@'localhost' IDENTIFIED BY 'Paste the copied password';
  flush privileges;

2.2. Reconfigure the user privileges:
  GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK
  TABLES ON *.* TO 'debian-sys-maint'@'localhost';
  flush privileges;
  exit

3. Test the operation. Should be OK (no output)
sudo logrotate -f /etc/logrotate.conf

I did not check, is the password proper by default (now it is impossible). If yes, only steps 2.2 and 3 are necessary. It can be tested only before step 2.1.

If the settings for 'debian-sys-maint' are secure, they should be set by default at the installation of (L/K/X)Ubunutu 20.04. If the settings are vulnerable, another solution should be found.

affects: samba (Ubuntu) → mysql-8.0 (Ubuntu)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I came by trying to clean old bugs that got forgotten.
But I wonder how the debian-sys-maint should have too few permissions.

It is created like:
CREATE USER IF NOT EXISTS 'debian-sys-maint'@'localhost' IDENTIFIED BY ...
GRANT ALL ON *.* TO 'debian-sys-maint'@'localhost' WITH GRANT OPTION;

That should be equal or better to what was suggested.
But then this is quite complex, checking a fresh install I found that we indeed have grants for root@localhost but none for debian-sys-maint@localhost.
But would we even need it?
The only thing the logrotate of mysqld (in /etc/logrotate.d/mysql-server) does in that regard is to issue this command:
  "/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping"
That you can try as well, it works on a default install right out of the box.

root@j:~# /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping
mysqld is alive

--

Sorry I was trying to clean up or shed new live to the bug.
But after staring at it for a while and trying to recreate this I'm wondering if we are missing something.
Setting to incomplete to reflect that.

Changed in mysql-8.0 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for mysql-8.0 (Ubuntu) because there has been no activity for 60 days.]

Changed in mysql-8.0 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.