Bug 1471306 - MariaDB fails to start after upgrade to F26 (OpenVZ)
MariaDB fails to start after upgrade to F26 (OpenVZ)
Status: NEW
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-01-05 06:14 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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
Launchpad 1691096 None None None 2017-07-14 20:06 EDT
Github https://github.com/systemd/systemd/issues/6281 None None None 2017-07-17 12:33 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?

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