Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ConditionNeedsUpdate needs /usr to have newer modification time than /etc #1628

Closed
peterbaouoft opened this issue Jun 15, 2018 · 7 comments
Closed

ConditionNeedsUpdate needs /usr to have newer modification time than /etc #1628

peterbaouoft opened this issue Jun 15, 2018 · 7 comments

Comments

@peterbaouoft
Copy link
Contributor

Hi,
For /usr on Atomic host, the modification time is canonicalized to epoch (1970) by ostree, and this makes /usr always older than /etc.

However, to have system-sysusers( or any service with ConditionNeedsUpdate ) to trigger automatically during boot time, /usr needs to be newer than /etc due to ConditionNeedsUpdate=/etc in the service file:

[rbao@unused-10-15-17-147 ~]$ cat /usr/lib/systemd/system/systemd-sysusers.service 
[Unit]
Description=Create System Users
Documentation=man:sysusers.d(5) man:systemd-sysusers.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-remount-fs.service
Before=sysinit.target shutdown.target systemd-update-done.service
ConditionNeedsUpdate=/etc

 ................................................

Reading a bit from systemd code base, it seems like ConditionNeedsUpdate needs /usr to be strictly newer than /etc (i.e only > and not >=). See code and documentation.

Endless seem to already have an implementation to fix this: Related commit: endlessm/ostree@9ef61fd \o/
Migrated from coreos/rpm-ostree#1415
@peterbaouoft peterbaouoft mentioned this issue Jun 15, 2018
Closed
@peterbaouoft peterbaouoft changed the title Question: modification time between /usr and /etc ConditionNeedsUpdate needs /usr to have newer modification time than /etc Jun 15, 2018
@cgwalters
Copy link
Member

The idea behind endlessm/ostree@9ef61fd seems generally OK to me. I just have minor code style nits, and it'd be good to have a test.

@dbnicholson I vaguely recall this came up before - let's try to get this upstream?

@cgwalters
Copy link
Member

@peterbaouoft Would you mind testing this patch fixes the problem for rpm-ostree+sysusers?

@peterbaouoft
Copy link
Contributor Author

@peterbaouoft Would you mind testing this patch fixes the problem for rpm-ostree+sysusers?

No, not at all, will be trying it out =).

@peterbaouoft
Copy link
Contributor Author

Yup, it does fix the problem for ConditionNeedsUpdate =). Now systemd-sysusers is triggered at boot time \o/.

@dbnicholson
Copy link
Member

@cgwalters yes, please. My cleaner version with tests (based on 2018.4, don't have time to rebase on master at the moment) is in dbnicholson@6b3d0cc.

@dbnicholson
Copy link
Member

BTW, this is also https://bugzilla.gnome.org/show_bug.cgi?id=752950.

dbnicholson added a commit to dbnicholson/ostree that referenced this issue Jun 18, 2018
@dbnicholson
deploy: Delete .updated file from /etc and /var on new deployments
19d1884 
Systemd units using ConditionNeedsUpdate run if the mtime of .updated in
the specified directory is newer than /usr. Since /usr has an mtime of
0, there's no way to have an older .updated file. Systemd units
typically specify ConditionNeedsUpdate=/etc or ConditionNeedsUpdate=/var
to support stateless systems like ostree.

Remove the file from the new deployment's /etc and the OS's /var
regardless of where they came from to ensure that these systemd units
run when booting new deployments. This will provide a method to run
services only on upgrade.

Closes: ostreedev#1628
https://bugzilla.gnome.org/show_bug.cgi?id=752950
@dbnicholson dbnicholson mentioned this issue Jun 18, 2018
Closed
@dbnicholson
Copy link
Member

I rebased my branch now in #1631 and it passes locally.

@alex285 alex285 mentioned this issue May 25, 2020
Closed
@cgwalters cgwalters mentioned this issue Aug 30, 2023
Closed
@travier travier mentioned this issue Oct 6, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cgwalters @dbnicholson @peterbaouoft