Bug 1268349 - systemd-readahead touches /.readhead
systemd-readahead touches /.readhead
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts (Show other bugs)
7.2
Unspecified Unspecified
high Severity medium
: rc
: ---
Assigned To: David Kaspar [Dee'Kej]
qe-baseos-daemons
:
Depends On:
Blocks: 1438583 1444018 1445812 1465901
  Show dependency treegraph
 
Reported: 2015-10-02 11:13 EDT by Fabian Deutsch
Modified: 2017-08-04 16:01 EDT (History)
11 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)

  None (edit)
Description Fabian Deutsch 2015-10-02 11:13:37 EDT
Description of problem:
It seems that systemd-readahead collect tries to touch/create/write /.readahead.
This leads to an error on systems where / is read-only.

Can't read-ahead touch a different file?

Version-Release number of selected component (if applicable):
RHEL 7

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Lukáš Nykrýn 2015-10-05 06:33:55 EDT
Yep we can probably do that. But it is 7.3 material.
Comment 3 Trinh Dao 2017-01-18 16:39:39 EST
RH, any update on this bug?
Comment 4 Trinh Dao 2017-01-18 16:42:41 EST
HPE bug is 1191750.
Comment 8 Michal Sekletar 2017-04-28 06:13:56 EDT
I think simple ConditionPathIsReadWrite should do the trick. Hence we would skip collecting read-ahead profile when / is read-only. That would mean users won't get benefits of read-ahead on such systems, but I recon not that many people care for read-ahead these days.

If we use different file then we could run into the same issue.
Comment 10 Michal Sekletar 2017-04-28 10:05:18 EDT
(In reply to Michal Sekletar from comment #8)
> I think simple ConditionPathIsReadWrite should do the trick. Hence we would
> skip collecting read-ahead profile when / is read-only. That would mean
> users won't get benefits of read-ahead on such systems, but I recon not that
> many people care for read-ahead these days.
> 
> If we use different file then we could run into the same issue.

Lukas pointed out that adding condition doesn't cut it, because we need to check the condition after rootfs was remounted. However we can't simply add After=systemd-remount-fs.service, because that would introduce circular dependency.

We need to figure out something else.
Comment 12 Michal Sekletar 2017-05-04 11:29:31 EDT
Currently when one enables read-only root via /etc/sysconfig/readonly-root it is still necessary to specify "ro" option for rootfs mount in fstab to actually get read-only filesystem. This is a bug in initscripts. 

Proposed solution is to have generator that parses /etc/sysconfig/readonly-root and changes generated mount unit so that rootfs is actually mounted read-only w/o user intervention in fstab. Same generator could also runtime mask systemd-readahead-collect.service in such case.

Reassigning to initscripts.
Comment 13 Trinh Dao 2017-08-04 16:01:46 EDT
JoeK, our HPE 1191750 is already closed as won't fix so I am marking HPE verified on this bug.

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