Bug 1471306 - MariaDB fails to start after upgrade to F26 (OpenVZ)
MariaDB fails to start after upgrade to F26 (OpenVZ)
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
26
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-14 20:06 EDT by Jiri Eischmann
Modified: 2018-05-29 08:29 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-05-29 08:29:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github https://github.com/systemd/systemd/issues/6281 None None None 2017-07-17 12:33 EDT
Launchpad 1691096 None None None 2017-07-14 20:06 EDT

  None (edit)
Description Jiri Eischmann 2017-07-14 20:06:26 EDT
MariaDB fails to start after upgrading to Fedora 26 with the following error messages:

Jul 15 02:02:43 vps systemd[18272]: mariadb.service: Failed at step KEYRING spawning /usr/libexec/mysql-check-socket: Permission denied
Jul 15 02:02:43 vps systemd[1]: mariadb.service: Control process exited, code=exited status=237
Jul 15 02:02:43 vps systemd[18275]: mariadb.service: Failed at step KEYRING spawning /usr/libexec/mysql-wait-stop: Permission denied
Jul 15 02:02:43 vps systemd[1]: mariadb.service: Control process exited, code=exited status=237

The system runs in OpenVZ container on the top of RHEL 7 kernel. It may be related to the linked bug.
Comment 1 Honza Horak 2017-07-17 06:11:31 EDT
Which version of mariadb it is exactly?
Comment 2 Jiri Eischmann 2017-07-17 06:29:51 EDT
I had to rollback to F25, so I can't tell. But I'll clone that VM to a playground and try an upgrade one more time and let you know.
Comment 3 Honza Horak 2017-07-17 06:34:05 EDT
then it was probably latest f26 as of 2017-07-14.. which was mariadb-10.1.25-1.fc26
Comment 4 Jiri Eischmann 2017-07-17 07:36:14 EDT
Yes, it is. Already running an upgraded VM in a playground and I can reproduce it again, let me know if you need any other info.
Comment 5 Jiri Eischmann 2017-07-17 09:53:51 EDT
It's in the combination with systemd 233. When I install 232 in F26, mariadb starts and runs flawlessly.
Comment 6 Honza Horak 2017-07-17 10:37:53 EDT
Moving to systemd component, since I don't have an idea what we might do wrong in mariadb.
Comment 7 Michal Sekletar 2017-07-17 12:27:40 EDT
By default kernel keyring is tied to UID so all system services that run as root share keyring, which is undesirable. Hence systemd always sets up "session" keyring that is per service.

OpenVZ is out-of-tree containerization technology and I have no idea how it works wrt. kernel keyring.
Comment 8 Zbigniew Jędrzejewski-Szmek 2017-07-17 12:33:40 EDT
See linked bug. It seems that somebody who has access to OpenVZ should prep a patch and verify that it works.
Comment 9 Jiri Eischmann 2017-07-19 09:58:07 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> See linked bug. It seems that somebody who has access to OpenVZ should prep
> a patch and verify that it works.

Is there already a patch submitted somewhere? I only see a proposed 2 lines of code from Lennart. I'm not familiar with systemd codebase to make a patch and apply it myself, but if someone makes a patched version of system I'll be more than happy to test it and verify if it really fixes the issue.
Comment 10 Zbigniew Jędrzejewski-Szmek 2017-07-19 10:53:10 EDT
There's no patch right now.
Comment 11 Jiri Eischmann 2017-11-11 17:38:00 EST
It may be a coincidence or it may be a working workaround: I managed to start the service using good old init script. Is it possible that systemd only attempts keyring for services which are started by unit files?
Comment 12 Fedora End Of Life 2018-05-03 04:09:52 EDT
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2018-05-29 08:29:28 EDT
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.