[MDEV-26317] Distributed mariadb.service Systed service file prevents start with default datadir - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.6.2, 10.2.39, 10.3.30, 10.4.20, 10.5.11
Fix Version/s: 10.3.33, 10.4.23, 10.5.14, 10.6.6, 10.7.2
Component/s: Packaging
Labels:
None

Description

When using our -systemd- binary tarballs the distributed mysqld.service systemd service file has

ProtectSystem=full

set since ~~MDEV-10298~~. As this leads to everything under /usr being read-only, but the binary tarball builds having the data dir set up under /usr/local/mariadb-.../data by default.

So trying to bring the MariaDB server up using default settings, according to our instructions in

https://mariadb.com/kb/en/installing-mariadb-binary-tarball

leads to "funny" errors like:

2021-08-06 10:44:49 0 [ERROR] mysqld: File '/usr/local/mariadb-10.4.18-linux-systemd-x86_64/data/aria_log_control' not found (Errcode: 30 "Read-only file system")

while starting the server manually works just fine.

So I'd suggest to add

ReadWritePaths=/usr/local/mysql/data

to the bundled mariadb.service file. As /usr/local/mysql/data is a symlink, and SystemD resolves this link to the actual data directory, this should work across all releases without requiring per-release adjustments.

A more complete fix would be to allow both the symlink and the actual versioned path, like e.g.:

ReadWritePaths=/usr/local/mysql/data /usr/local/mariadb-10.4.18-linux-systemd-x86_64/data/

Attachments

Issue Links

is caused by

MDEV-10298 Improve systemd service hardening

Closed

relates to

MDEV-25177 Better indication of refusing to start because of ProtectHome

Closed

Activity

Ascending order - Click to sort in descending order

Hartmut Holzgraefe created issue - 2021-08-06 13:11

Hartmut Holzgraefe made changes - 2021-08-06 13:11

Field	Original Value	New Value
Link		This issue is caused by ~~MDEV-10298~~ [ ~~MDEV-10298~~ ]

Hartmut Holzgraefe added a comment - 2021-08-06 14:13

Unfortunately the ReadWritePaths approach only works with CentOS 8, not with CentOS 7 ...

Hartmut Holzgraefe added a comment - 2021-08-06 14:13 Unfortunately the ReadWritePaths approach only works with CentOS 8, not with CentOS 7 ...

Hartmut Holzgraefe added a comment - 2021-08-06 14:31 - edited

pre Systemd 231 the setting name is ReadWriteDirectories, not ReadWritePaths

As CentOS 7 / RHEL 7 come with SystenD 219 the older ReadWriteDirectories is needed there

Hartmut Holzgraefe added a comment - 2021-08-06 14:31 - edited pre Systemd 231 the setting name is ReadWriteDirectories, not ReadWritePaths As CentOS 7 / RHEL 7 come with SystenD 219 the older ReadWriteDirectories is needed there

Daniel Black made changes - 2021-08-23 09:39

Assignee

Tuukka Pasanen [ JIRAUSER49166 ]

Tuukka Pasanen made changes - 2021-08-23 10:37

Link

This issue is blocked by ~~MDEV-25177~~ [ ~~MDEV-25177~~ ]

Tuukka Pasanen added a comment - 2021-08-23 10:40

hholzgra did I understand correctly that you are using binary tar-ball not DEB or RPM installation with read-only /usr and you use MariaDB-systemd to launch you instance?

Tuukka Pasanen added a comment - 2021-08-23 10:40 hholzgra did I understand correctly that you are using binary tar-ball not DEB or RPM installation with read-only /usr and you use MariaDB-systemd to launch you instance?

Daniel Black added a comment - 2021-09-01 00:07

> using binary tar-ball not DEB or RPM installation

yes.

> with read-only /usr

No, ProtectSystem=full makes /usr read only.

> and you use MariaDB-systemd to launch you instance?

Yes the systemd service file is used to start the service.

Daniel Black added a comment - 2021-09-01 00:07 > using binary tar-ball not DEB or RPM installation yes. > with read-only /usr No, ProtectSystem=full makes /usr read only. > and you use MariaDB-systemd to launch you instance? Yes the systemd service file is used to start the service.

Sergei Golubchik made changes - 2021-10-05 14:24

Fix Version/s		10.2 [ 14601 ]
Fix Version/s		10.3 [ 22126 ]
Fix Version/s		10.4 [ 22408 ]
Fix Version/s		10.5 [ 23123 ]
Fix Version/s		10.6 [ 24028 ]

Daniel Black made changes - 2021-11-16 11:17

Assignee

Tuukka Pasanen [ JIRAUSER49166 ]

Daniel Black [ danblack ]

Tuukka Pasanen added a comment - 2021-12-03 10:29

hholzgra Could you test Pull Request does it work around this problem?

Tuukka Pasanen added a comment - 2021-12-03 10:29 hholzgra Could you test Pull Request does it work around this problem?

Sergei Golubchik made changes - 2021-12-06 21:35

Workflow

MariaDB v3 [ 124141 ]

MariaDB v4 [ 143071 ]

Tuukka Pasanen added a comment - 2021-12-20 12:07

This PR has been merged

Tuukka Pasanen added a comment - 2021-12-20 12:07 This PR has been merged

Tuukka Pasanen made changes - 2021-12-20 12:07

Component/s		Packaging [ 10700 ]
Fix Version/s		N/A [ 14700 ]
Fix Version/s	10.2 [ 14601 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Fix Version/s	10.5 [ 23123 ]
Fix Version/s	10.6 [ 24028 ]
Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Vicențiu Ciorbaru added a comment - 2021-12-20 12:33

illuusio The PR https://github.com/MariaDB/server/pull/1949 is still open. Where exactly has this been merged? What branch?

Also, when fixing a bug in a version (say 10.3), the Fix Version you need to fill out in JIRA is 10.[34567].<next-upcoming-point-release>. Basically, you need to mark which upcoming versions will have the bug fixed, so that it's easy to figure out which version has it.

Vicențiu Ciorbaru added a comment - 2021-12-20 12:33 illuusio The PR https://github.com/MariaDB/server/pull/1949 is still open. Where exactly has this been merged? What branch? Also, when fixing a bug in a version (say 10.3), the Fix Version you need to fill out in JIRA is 10. [34567] .<next-upcoming-point-release>. Basically, you need to mark which upcoming versions will have the bug fixed, so that it's easy to figure out which version has it.

Tuukka Pasanen added a comment - 2021-12-20 13:20

cvicentiu I tried but it just said that it doesn't fit in to regex..

Tuukka Pasanen added a comment - 2021-12-20 13:20 cvicentiu I tried but it just said that it doesn't fit in to regex..

Sergei Golubchik added a comment - 2021-12-20 13:32

doesn't seem to be merged anywhere

Sergei Golubchik added a comment - 2021-12-20 13:32 doesn't seem to be merged anywhere

Tuukka Pasanen added a comment - 2021-12-20 13:48

serg Sorry my bad.. I just looked GIthub very straigly it was approved not merged!.. I re-open if I can

Tuukka Pasanen added a comment - 2021-12-20 13:48 serg Sorry my bad.. I just looked GIthub very straigly it was approved not merged!.. I re-open if I can

Tuukka Pasanen made changes - 2021-12-20 13:50

Fix Version/s		10.3 [ 22126 ]
Fix Version/s		10.4 [ 22408 ]
Fix Version/s		10.5 [ 23123 ]
Fix Version/s		10.6 [ 24028 ]
Fix Version/s		10.7 [ 24805 ]
Fix Version/s	N/A [ 14700 ]

Tuukka Pasanen added a comment - 2021-12-20 13:52

This just Approved not merged.

Tuukka Pasanen added a comment - 2021-12-20 13:52 This just Approved not merged.

Tuukka Pasanen made changes - 2021-12-20 13:52

Resolution	Fixed [ 1 ]
Status	Closed [ 6 ]	Stalled [ 10000 ]

Daniel Black made changes - 2022-01-07 06:52

Fix Version/s		10.3.33 [ 26805 ]
Fix Version/s		10.4.23 [ 26807 ]
Fix Version/s		10.5.14 [ 26809 ]
Fix Version/s		10.6.6 [ 26811 ]
Fix Version/s		10.7.2 [ 26813 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Fix Version/s	10.5 [ 23123 ]
Fix Version/s	10.6 [ 24028 ]
Fix Version/s	10.7 [ 24805 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Daniel Black made changes - 2022-01-07 07:34

Link

This issue is blocked by ~~MDEV-25177~~ [ ~~MDEV-25177~~ ]

Daniel Black made changes - 2022-01-07 07:34

Link

This issue relates to ~~MDEV-25177~~ [ ~~MDEV-25177~~ ]

Hartmut Holzgraefe added a comment - 2022-01-07 07:51

Just by coincidence I ran into the same yesterday (didn't even really remember I had encountered it before, and especially not that I created this ticked), and for now updated the KB entries on tarball installation and on systemD to mention this problem and how to deal with it with a simple extra systemd service include file:

https://mariadb.com/kb/en/installing-mariadb-binary-tarballs/#auto-start-of-mysqld

https://mariadb.com/kb/en/systemd/#configuring-the-data-directory

Hartmut Holzgraefe added a comment - 2022-01-07 07:51 Just by coincidence I ran into the same yesterday (didn't even really remember I had encountered it before, and especially not that I created this ticked), and for now updated the KB entries on tarball installation and on systemD to mention this problem and how to deal with it with a simple extra systemd service include file: https://mariadb.com/kb/en/installing-mariadb-binary-tarballs/#auto-start-of-mysqld https://mariadb.com/kb/en/systemd/#configuring-the-data-directory

Sergei Golubchik made changes - 2022-03-08 19:13

Description

When using our -systemd- binary tarballs the distributed mysqld.service systemd service file has

{noformat}
ProtectSystem=full
{noformat}

set since ~~MDEV-10298~~. As this leads to everything under /usr being read-only, but the binary tarball builds having the data dir set up under /usr/local/mariadb-.../data by default.

So trying to bring the MariaDB server up using default settings, according to our instructions in

https://mariadb.com/kb/en/installing-mariadb-binary-tarball

leads to "funny" errors like:

{noformat}
2021-08-06 10:44:49 0 [ERROR] mysqld: File '/usr/local/mariadb-10.4.18-linux-systemd-x86_64/data/aria_log_control' not found (Errcode: 30 "Read-only file system")
{noformat}

while starting the server manually works just fine.

So I'd suggest to add

{noformat}
ReadWritePaths=/usr/local/mysql/data
{noformat}

to the bundled mariadb.service file. As /usr/local/mysql/data is a symlink, and SystemD resolves this link to the actual data directory, this should work across all releases without requiring per-release adjustments.

A more complete fix would be to allow both the symlink and the actual versioned path, like e.g.:

{noformat}
ReadWritePaths=/usr/local/mysql/data /usr/local/mariadb-10.4.18-linux-systemd-x86_64/data/
{noformat}

When using our \-systemd- binary tarballs the distributed mysqld.service systemd service file has

{noformat}
ProtectSystem=full
{noformat}

set since ~~MDEV-10298~~. As this leads to everything under /usr being read-only, but the binary tarball builds having the data dir set up under /usr/local/mariadb-.../data by default.

So trying to bring the MariaDB server up using default settings, according to our instructions in

https://mariadb.com/kb/en/installing-mariadb-binary-tarball

leads to "funny" errors like:

{noformat}
2021-08-06 10:44:49 0 [ERROR] mysqld: File '/usr/local/mariadb-10.4.18-linux-systemd-x86_64/data/aria_log_control' not found (Errcode: 30 "Read-only file system")
{noformat}

while starting the server manually works just fine.

So I'd suggest to add

{noformat}
ReadWritePaths=/usr/local/mysql/data
{noformat}

to the bundled mariadb.service file. As /usr/local/mysql/data is a symlink, and SystemD resolves this link to the actual data directory, this should work across all releases without requiring per-release adjustments.

A more complete fix would be to allow both the symlink and the actual versioned path, like e.g.:

{noformat}
ReadWritePaths=/usr/local/mysql/data /usr/local/mariadb-10.4.18-linux-systemd-x86_64/data/
{noformat}

People

Assignee:: Daniel Black

Reporter:: Hartmut Holzgraefe

Votes:: 0 Vote for this issue

Watchers:: 5 Start watching this issue

Dates

Created:: 2021-08-06 13:11

Updated:: 2022-03-08 19:13

Resolved:: 2022-01-07 06:52

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration