postinst fails when daemon is not running (or is disabled by policy-rc.d)

I've discussed this with Lars. The problem is that we need to run mysql_upgrade in the postinst as it is expected that /var/lib/mysql is upgraded when the package is upgraded. However, mysql_upgrade requires the daemon to be running, and the daemon must be restarted after it is finished running. This is tricky to do in a postinst with respect to policy-rc.d.

I think this is the more general case of this specific bug.

We moved mysql_upgrade to the postinst from the upstart service script in 5.7 when we did the systemd work. Otherwise we struggle to restart mysqld after mysql_upgrade has run.

I think the solution is to consider the daemon start/stop for the purposes of mysql_upgrade outside the scope of policy-rc.d, while ensuring that it doesn't appear to be running during that time to anything else. For example, run it with TCP disabled and on a Unix socket in a temporary location only, just for the purpose of mysql_upgrade to talk to it. Then it would effectively be the same as running a version of mysql_upgrade that does not require a running daemon. This special start/stop of mysqld could use start-stop-daemon with a custom configuration to run with TCP disabled and put the pidfile and Unix socket in a temporary location. I'm told that mysqld will fail to start if it cannot get an exclusive lock on specific files inside /var/lib/mysql, so we should be safe from concurrent access issues with a daemon we do not know about.

However, if policy-rc.d means that a daemon remains running when the postinst is running, we will just not be able to run mysql_upgrade. Perhaps we should warn in this case.

I have the same issue with the newer package 5.7_5.7.13 as well:

sudo apt-get install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  mysql-server-5.7 mysql-server-core-5.7
Suggested packages:
  mailx tinyca
The following NEW packages will be installed:
  mysql-server-5.7 mysql-server-core-5.7
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0 B/10.4 MB of archives.
After this operation, 94.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Preconfiguring packages ...
(Reading database ... 277327 files and directories currently installed.)
Preparing to unpack .../mysql-server-core-5.7_5.7.13-0ubuntu0.16.04.2_amd64.deb ...
Unpacking mysql-server-core-5.7 (5.7.13-0ubuntu0.16.04.2) ...
dpkg: error processing archive /var/cache/apt/archives/mysql-server-core-5.7_5.7.13-0ubuntu0.16.04.2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/mysql/charsets/greek.xml', which is also in package mysql-common 5.7.13-1ubuntu14.04
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Preparing to unpack .../mysql-server-5.7_5.7.13-0ubuntu0.16.04.2_amd64.deb ...
grep: /etc/mysql/: No such file or directory
Unpacking mysql-server-5.7 (5.7.13-0ubuntu0.16.04.2) ...
dpkg: error processing archive /var/cache/apt/archives/mysql-server-5.7_5.7.13-0ubuntu0.16.04.2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/mysql/errmsg-utf8.txt', which is also in package mysql-common 5.7.13-1ubuntu14.04
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-4ubuntu7) ...
Errors were encountered while processing:
 /var/cache/apt/archives/mysql-server-core-5.7_5.7.13-0ubuntu0.16.04.2_amd64.deb
 /var/cache/apt/archives/mysql-server-5.7_5.7.13-0ubuntu0.16.04.2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
antunes@iMac12-2-0:~$ sudo apt-get remove mysql-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  mysql-server
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 164 kB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 277325 files and directories currently installed.)
Removing mysql-server (5.7.13-0ubuntu0.16.04.2) ...

Apparently what had solved my problem is the following:

 1925 sudo apt-get purge mysql-server mysql-client
 2029 sudo deluser mysql
 2030 sudo delgroup mysql
 2031 sudo rm -rf /var/log/mysql/
 2033 sudo apt-get install mysql-server mysql-client

Which seems to me that the install procedure does not like that it had the user and group before from previous version.

The "trying to overwrite" error seems to be because you are going from the upstream packages to the native ones, and they're a bit different in which packages have some of the files.
So it's probably the apt-get purge command that fixed it (unless you tried that on its own before without luck?), since that would remove the conflicting files from the 14.04 package.

So two things we need:

* If we can't stop/start the daemon through the service system, start it manually in a "hidden" way.

* If we can't access the database (because an older daemon has locked it), don't fail the installation, but warn the user that mysql_upgrade hasn't been run

Agreed, though:

> If we can't stop/start the daemon through the service system, start it manually in a "hidden" way.

Is there any point of bothering with the "if"? We could simply the code by doing it all the time anyway.

I am having a issue with a new install of 16.04.01:

trsbox:~$ mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

trsbox:~$ mysqladmin -u root -p status
Enter password:
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

trsbox:~$ sudo systemctl enable mysql
[sudo] password for scorch:
Synchronizing state of mysql.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable mysql

trsbox:~$ sudo service mysql start
Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.

trsbox:~$ systemctl status mysql.service
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: activating (start-post) (Result: exit-code) since Fri 2017-02-17 12:54:34 EST; 17s ago
  Process: 4248 ExecStart=/usr/sbin/mysqld (code=exited, status=2)
  Process: 4244 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 4248 (code=exited, status=2); : 4249 (mysql-systemd-s)
    Tasks: 2
   Memory: 12.3M
      CPU: 730ms
   CGroup: /system.slice/mysql.service
           └─control
             ├─4249 /bin/bash /usr/share/mysql/mysql-systemd-start post
             └─4314 sleep 1

And:

trsbox:~$ sudo journalctl -xe
Feb 17 13:01:41 trsbox.net audit[5682]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=5682 comm="mysqld" requested_mask="r"
Feb 17 13:01:41 trsbox.net audit[5682]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/5682/status" pid=5682 comm="mysqld" requested_mask="r" denied_
Feb 17 13:01:41 trsbox.net kernel: audit: type=1400 audit(1487354501.565:143): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/5682/status" pid=5682 comm=
Feb 17 13:01:41 trsbox.net kernel: audit: type=1400 audit(1487354501.565:144): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=56
Feb 17 13:01:41 trsbox.net kernel: audit: type=1400 audit(1487354501.565:145): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/5682/status" pid=5682 comm=
Feb 17 13:01:41 trsbox.net systemd[1]: mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 17 13:01:42 trsbox.net sshd[5648]: Failed password for root from 183.214.141.101 port 19744 ssh2
Feb 17 13:01:43 trsbox.net sshd[5652]: Failed password for root from 123.183.209.136 port 19999 ssh2
Feb 17 13:01:44 trsbox.net sshd[5652]: Received disconnect from 123.183.209.136 port 19999:11: [preauth]
Feb 17 13:01:44 trsbox.net sshd[5652]: Disconnected from 123.183.209.136 port 19999 [preauth]
Feb 17 13:01:44 trsbox.net sshd[5652]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.183.209.136 user=root
Feb 17 13:01:46 trsbox.net sshd[5648]: Failed password for root from 183.214.141.101 port 19744 ssh2
Feb 17 13:01:48 trsbox.net sshd[5648]: Failed password for root from 183.214.141.101 port 19744 ssh2
Feb 17 13:01:48 trsbox.net sshd[5648]: error: maximum authentication attempts exceeded for root from 183.214.141.101 port 19744 ssh2 [preauth]
Feb 17 13:01:48 trsbox.net sshd[5648]: Disconnecting: Too many authentication failures [preauth]
Feb 17 13:01:48 trsbox.net sshd[5648]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.214.141.101 user=root
Feb 17 13:01:48 trsbox.net sshd[5648]: PAM service(sshd) ignoring max retries; 6 > 3
Feb 17 13:01:50 trsbox.net sshd[5729]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Feb 17 13:01:50 trsbox.net sshd[5729]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 17 13:01:51 trsbox.net sshd[5729]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.214.141.101 user=root
Feb 17 13:01:52 trsbox.net sshd[5737]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Feb 17 13:01:52 trsbox.net sshd[5737]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 17 13:01:53 trsbox.net sshd[5739]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Feb 17 13:01:53 trsbox.net sshd[5739]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 17 13:01:53 trsbox.net sshd[5729]: Failed password for root from 183.214.141.101 port 47025 ssh2
Feb 17 13:01:54 trsbox.net sshd[5737]: pam_unix(sshd:auth): authentica...

Same for me, on Xenial...

(add .log for force upgrading...)

sudo systemctl enable mysql
sudo systemctl start mysql
sudo apt install -f

Upgrade process completed successfully. :)

That's ok, but I guess a better approach would be delaying upgrade (no
install) if service is disabled or doing these steps automatically because
it can be very annoying and could mess something up.
The first option should be a bit easier to implement.

2017-04-28 17:08 GMT-03:00 Larika <email address hidden>:

> sudo systemctl enable mysql
> sudo systemctl start mysql
> sudo apt install -f
>
> Upgrade process completed successfully. :)
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1658034).
> https://bugs.launchpad.net/bugs/1592669
>
> Title:
> postinst fails when daemon is not running (or is disabled by policy-
> rc.d)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/
> 1592669/+subscriptions
>

But, why the service has to be enabled to upgrade it?

El 29/4/2017 5:34, "Jordao" <email address hidden> escribió:

> That's ok, but I guess a better approach would be delaying upgrade (no
> install) if service is disabled or doing these steps automatically because
> it can be very annoying and could mess something up.
> The first option should be a bit easier to implement.
>
> 2017-04-28 17:08 GMT-03:00 Larika <email address hidden>:
>
> > sudo systemctl enable mysql
> > sudo systemctl start mysql
> > sudo apt install -f
> >
> > Upgrade process completed successfully. :)
> >
> > --
> > You received this bug notification because you are subscribed to a
> > duplicate bug report (1658034).
> > https://bugs.launchpad.net/bugs/1592669
> >
> > Title:
> > postinst fails when daemon is not running (or is disabled by policy-
> > rc.d)
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/
> > 1592669/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1595208).
> https://bugs.launchpad.net/bugs/1592669
>
> Title:
> postinst fails when daemon is not running (or is disabled by policy-
> rc.d)
>
> Status in mysql-5.7 package in Ubuntu:
> In Progress
> Status in mysql-5.7 package in Debian:
> New
>
> Bug description:
> Every 10-15 minutes mysql crashes with this error.
>
> ProblemType: Package
> DistroRelease: Ubuntu 16.04
> Package: mysql-server-5.7 5.7.12-0ubuntu1
> ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10
> Uname: Linux 4.4.0-24-generic x86_64
> ApportVersion: 2.20.1-0ubuntu2.1
> Architecture: amd64
> Date: Fri Jun 10 10:47:34 2016
> ErrorMessage: subprocess installed post-installation script returned
> error exit status 1
> InstallationDate: Installed on 2002-01-01 (5279 days ago)
> InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64
> (20140722.2)
> Logs.var.log.daemon.log:
>
> Logs.var.log.mysql.error.log:
> MySQLConf.etc.mysql.conf.d.mysql.cnf: [mysql]
> MySQLConf.etc.mysql.conf.d.mysqld_safe_syslog.cnf:
> [mysqld_safe]
> syslog
> MySQLConf.etc.mysql.conf.d.mysqldump.cnf:
> [mysqldump]
> quick
> quote-names
> max_allowed_packet = 16M
> MySQLConf.etc.mysql.mysql.conf.d.mysqld_safe_syslog.cnf:
> [mysqld_safe]
> syslog
> MySQLVarLibDirListing: ['joomla', 'debian-5.7.flag',
> 'performance_schema', 'mysql', 'debian-5.5.flag', 'ibdata1', 'ib_logfile1',
> 'mysql_upgrade_info', 'ibtmp1', 'auto.cnf', 'sys', 'ib_logfile0',
> 'ib_buffer_pool']
> ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-24-generic
> root=UUID=24616351-e938-44c6-b79f-5db042b2563b ro quiet splash
> vt.handoff=7
> RelatedPackageVersions:
> dpkg 1.18.4ubuntu1.1
> apt 1.2.12~ubuntu16.04.1
> SourcePackage: mysql-5.7
> Title: package mysql-server-5.7 5.7.12-0ubuntu1 failed to
> install/upgrade: subprocess installed post-installation script returned
> error exit status 1
> UpgradeStatus: Upgraded to xenial on 2016-06-10 (4 days ago)
> upstart.mysql.override: manual
>
> To manage notifications about this bug go to:
> https://bugs.launchpad....

During an upgrade, there are queries that need to be run against the
server, which means the mysql service must be running.

On Apr 29, 2017 3:04 AM, "Pablo Catalina" <email address hidden> wrote:

But, why the service has to be enabled to upgrade it?

El 29/4/2017 5:34, "Jordao" <email address hidden> escribió:

> That's ok, but I guess a better approach would be delaying upgrade (no
> install) if service is disabled or doing these steps automatically because
> it can be very annoying and could mess something up.
> The first option should be a bit easier to implement.
>
> 2017-04-28 17:08 GMT-03:00 Larika <email address hidden>:
>
> > sudo systemctl enable mysql
> > sudo systemctl start mysql
> > sudo apt install -f
> >
> > Upgrade process completed successfully. :)
> >
> > --
> > You received this bug notification because you are subscribed to a
> > duplicate bug report (1658034).
> > https://bugs.launchpad.net/bugs/1592669
> >
> > Title:
> > postinst fails when daemon is not running (or is disabled by policy-
> > rc.d)
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/
> > 1592669/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1595208).
> https://bugs.launchpad.net/bugs/1592669
>
> Title:
> postinst fails when daemon is not running (or is disabled by policy-
> rc.d)
>
> Status in mysql-5.7 package in Ubuntu:
> In Progress
> Status in mysql-5.7 package in Debian:
> New
>
> Bug description:
> Every 10-15 minutes mysql crashes with this error.
>
> ProblemType: Package
> DistroRelease: Ubuntu 16.04
> Package: mysql-server-5.7 5.7.12-0ubuntu1
> ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10
> Uname: Linux 4.4.0-24-generic x86_64
> ApportVersion: 2.20.1-0ubuntu2.1
> Architecture: amd64
> Date: Fri Jun 10 10:47:34 2016
> ErrorMessage: subprocess installed post-installation script returned
> error exit status 1
> InstallationDate: Installed on 2002-01-01 (5279 days ago)
> InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64
> (20140722.2)
> Logs.var.log.daemon.log:
>
> Logs.var.log.mysql.error.log:
> MySQLConf.etc.mysql.conf.d.mysql.cnf: [mysql]
> MySQLConf.etc.mysql.conf.d.mysqld_safe_syslog.cnf:
> [mysqld_safe]
> syslog
> MySQLConf.etc.mysql.conf.d.mysqldump.cnf:
> [mysqldump]
> quick
> quote-names
> max_allowed_packet = 16M
> MySQLConf.etc.mysql.mysql.conf.d.mysqld_safe_syslog.cnf:
> [mysqld_safe]
> syslog
> MySQLVarLibDirListing: ['joomla', 'debian-5.7.flag',
> 'performance_schema', 'mysql', 'debian-5.5.flag', 'ibdata1',
'ib_logfile1',
> 'mysql_upgrade_info', 'ibtmp1', 'auto.cnf', 'sys', 'ib_logfile0',
> 'ib_buffer_pool']
> ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-24-generic
> root=UUID=24616351-e938-44c6-b79f-5db042b2563b ro quiet splash
> vt.handoff=7
> RelatedPackageVersions:
> dpkg 1.18.4ubuntu1.1
> apt 1.2.12~ubuntu16.04.1
> SourcePackage: mysql-5.7
> Title: package mysql-server-5.7 5.7.12-0ubuntu1 failed to
> install/upgrade: subprocess installed post-installation script retu...

There are two separate "upgrades" happening: Upgrading the package and
upgrading the database. The problem is that right now the former will
fail if the latter fails, but it doesn't need to.

I have a solution (still needs some more testing, but hopefully it will
be ready soon) that:

a) Tries to run the server directly instead of through the service
system, so it should work normally if the service is disabled as long as
the server isn't already running (since then we can't stop it).
b) Completes the package upgrade even if the server can't be started,
but without running mysql_upgrade.

--
Lars

On 04/29/2017 09:51 AM, Ben Landin wrote:
> During an upgrade, there are queries that need to be run against the
> server, which means the mysql service must be running.
>
> On Apr 29, 2017 3:04 AM, "Pablo Catalina" <email address hidden>
> wrote:
>
> But, why the service has to be enabled to upgrade it?
>
> El 29/4/2017 5:34, "Jordao" <email address hidden> escribió:
>
>> That's ok, but I guess a better approach would be delaying upgrade (no
>> install) if service is disabled or doing these steps automatically because
>> it can be very annoying and could mess something up.
>> The first option should be a bit easier to implement.
>>
>> 2017-04-28 17:08 GMT-03:00 Larika <email address hidden>:
>>
>>> sudo systemctl enable mysql
>>> sudo systemctl start mysql
>>> sudo apt install -f
>>>
>>> Upgrade process completed successfully. :)
>>>
>>> --
>>> You received this bug notification because you are subscribed to a
>>> duplicate bug report (1658034).
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_bugs_1592669&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg&m=PdAlVtFEw3yL55hI32gYfa72qnbSSi8VrBBgpGOqV9A&s=J_Ik4Rb7XaAgBURNKto_54-iFFIwX9Bopkj5F3xbY4I&e=
>>>
>>> Title:
>>> postinst fails when daemon is not running (or is disabled by policy-
>>> rc.d)
>>>
>>> To manage notifications about this bug go to:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_ubuntu_-2Bsource_mysql-2D5.7_-2Bbug_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg&m=PdAlVtFEw3yL55hI32gYfa72qnbSSi8VrBBgpGOqV9A&s=4q_iH3iF49qeYu7uFbOKBQC9aiQxFqWA8Ek4Yqf3Ay4&e=
>>> 1592669/+subscriptions
>>>
>> --
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (1595208).
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_bugs_1592669&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg&m=PdAlVtFEw3yL55hI32gYfa72qnbSSi8VrBBgpGOqV9A&s=J_Ik4Rb7XaAgBURNKto_54-iFFIwX9Bopkj5F3xbY4I&e=
>>
>> Title:
>> postinst fails when daemon is not running (or is disabled by policy-
>> rc.d)
>>
>> Status in mysql-5.7 package in Ubuntu:
>> In Progress
>> Status in mysql-5.7 package in Debian:
>> New
>>
>> Bug description:
>> Every 10-15 minutes mysql crashes with this error.
>>
>> ProblemType: Package
>> DistroRelease: Ubuntu 16.04
>> Package: mysql-server-5.7 5.7.12-0ubuntu1
>> ProcVersionSignature: Ubu...

If I can suggest, keep it simple.

if the service is disable :

enable
start if stopped
upgrade
stop if was stopped
disable

User will find package upgraded but in the same state as he left it.

If it's enabled, just check before if the service is loaded and upgrade.

I think it's important to give users an updated package, ready to use, as he left it.

Thanks for your work!

On 02. mai 2017 23:49, Larika wrote:
> If I can suggest, keep it simple.
>
> if the service is disable :
>
> enable
> start if stopped
> upgrade
> stop if was stopped
> disable
>
> User will find package upgraded but in the same state as he left it.
>
> If it's enabled, just check before if the service is loaded and upgrade.
>
> I think it's important to give users an updated package, ready to use,
> as he left it.
>
> Thanks for your work!
>
Ideally we'd always leave the package _and_ database in a fully upgraded
state, but I don't think we can/should override the user's service settings.
However, the only situation where we won't be able to upgrade the
database is if the service is disabled and the server is running; If the
service is disabled but the server is stopped, we'll start the server in
a manual way (in general we will no longer use the service system during
postinst) and run mysql_upgrade.

--
Lars.

At my home I keep Mysql usually disabled until I need it, but it may
happen, in a few cases, you might have an another mysql (custom install)
running.
Maybe the installer could open an dialog and asks if the user wants the
service to be started automatically for the upgrade (and then disabled) or
keep it unconfigured.

2017-05-03 1:40 GMT-03:00 Lars Tangvald <email address hidden>:

> On 02. mai 2017 23:49, Larika wrote:
> > If I can suggest, keep it simple.
> >
> > if the service is disable :
> >
> > enable
> > start if stopped
> > upgrade
> > stop if was stopped
> > disable
> >
> > User will find package upgraded but in the same state as he left it.
> >
> > If it's enabled, just check before if the service is loaded and upgrade.
> >
> > I think it's important to give users an updated package, ready to use,
> > as he left it.
> >
> > Thanks for your work!
> >
> Ideally we'd always leave the package _and_ database in a fully upgraded
> state, but I don't think we can/should override the user's service
> settings.
> However, the only situation where we won't be able to upgrade the
> database is if the service is disabled and the server is running; If the
> service is disabled but the server is stopped, we'll start the server in
> a manual way (in general we will no longer use the service system during
> postinst) and run mysql_upgrade.
>
> --
> Lars.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1658034).
> https://bugs.launchpad.net/bugs/1592669
>
> Title:
> postinst fails when daemon is not running (or is disabled by policy-
> rc.d)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/
> 1592669/+subscriptions
>

How do I get around this issue? I just got this error after getting an update today. I'm on 16.04.3

Hi Jun,
If you use mysql but have it off/disabled for some reason to get over this on upgrades until this is resolved:

1. enable the service so that it is started correctly
2. then do the update
3. then if you want disable it again.

If your service is instead stopped because you really no more use it, but now on upgrades you run into this issue - you might as well consider just removing the package.

Hi Christian,

Sorry, I was not very clear, and thank you for the prompt reply. I have tried the workaround before I posted my comment here. It does not work. Note I cannot uninstall MySQL. I need it. And yes, I don't want the service to run on boot, preferring to start it manually (Although I can change this of course, probably pads a couple milliseconds @ boot time but SSD speed is almost negligible). :)

From what I read above and in other reports, this is what I have done so far:
1) enable the service - systemctl enable mysql.service
2) start if not yet started - systemctl start mysql.service
3) apt upgrade

But it seems the `enable` command has some errors - sudo systemctl enable mysql.service

Result:
Synchronizing state of mysql.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable mysql
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides LSB defaults (2 3 4 5).
update-rc.d: error: no runlevel symlinks to modify, aborting!

Hi,

Sorry, this is on us: We've had a fix for this in review for a while, but haven't been able to push it to completion (it's a fairly big change to how the packaging works).

I'm not familiar with the error you're getting with the enable command (doesn't happen on my box. I get the warning but not the error), but a second workaround you can try until we can get this fix into the package is:
* Edit /var/lib/dpkg/info/mysql-server-5.7.postinst and put a simple "exit 0" at the top after #!/bin/bash
* Run apt-get -f install

This will skip the entire postinst script, which basically has two purposes:
a) On a fresh install, setup the default database, root access, etc.
b) On an upgrade, start the new server version, run mysql_upgrade, then restart the server

a) Shouldn't apply in your case, but it's important you do b)

Hopefully this helps

Ok, done and done. Thanks Lars.

This bug was fixed in the package mysql-5.7 - 5.7.21-1ubuntu1

---------------
mysql-5.7 (5.7.21-1ubuntu1) bionic; urgency=medium

  * Merge from Debian.
  * Remaining changes:
    - Revert "Build with libmecab-dev" since libmecab-dev is in
      universe.

mysql-5.7 (5.7.21-1) unstable; urgency=high (security fixes)

  * Imported upstream version 5.7.21 to fix security issues:
    - http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
    - CVE-2018-2562 CVE-2018-2565 CVE-2018-2573 CVE-2018-2576
    - CVE-2018-2583 CVE-2018-2586 CVE-2018-2590 CVE-2018-2591
    - CVE-2018-2600 CVE-2018-2612 CVE-2018-2622 CVE-2018-2640
    - CVE-2018-2645 CVE-2018-2646 CVE-2018-2647 CVE-2018-2665
    - CVE-2018-2667 CVE-2018-2668 CVE-2018-2696 CVE-2018-2703
    - CVE-2017-3737
    (Closes: #887477)

 -- Lars Tangvald <email address hidden> Fri, 02 Feb 2018 11:58:04 +0100

Coming from Bug #1605948.
Today the upgrade of mysql-server-5.7 from 5.7.30 to 5.7.31 failed on my Ubuntu 16.04-based system. Is it correct to say that this problem is still unresolved in 16.04?
I fixed the upgrade by enabling the service (having it running was not enough) before re-running "apt install mysql-server-5.7". Was not that easy to find it out though.

Hi Mauro,

Thanks for your follow-up comment and analysis in LP: #1605948, we are however not able to do debugging work or provide support for non-Ubuntu distributions. If you are able to provide steps to reproduce the issue in a clean Ubuntu system we'll certainly look into it, being glad to know that fixing it will also benefit the downstream distribution.

Should you do so I suggest you to file a new bug, referencing this one if relevant.

Paride

Hi Paride,
based on my experience and on what I read on these bug reports, the steps to repro are:

- have an Ubuntu system with mysql-server-5.7 version 5.7.30 installed
- systemctl stop mysql
- systemctl disable mysql
- apt install mysql-server-5.7 (in order to upgrade it to the latest version, which is 5.7.31 now)
=> postinst scripts fail with the mentioned error:

mysql_upgrade: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) while connecting to the MySQL server

Workaround:
- systemctl enable mysql (<= important!)
- systemctl start mysql
- apt install mysql-server-5.7

Anyway, there's a thorough analysis here and, if I understand this LP page, the fix was delivered to 16.09 (and hence inherited from subsequent releases) but not to 16.04, correct me if I'm wrong.

Correct Mauro, speaking in still active releases 16.04 (Xenial) is affected and >=18.04 (Bionic and later) is fixed.
Maybe there was a potential regression that was seen too risky for an SRU, I have no clear statement about it on the bug thou.