After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752950 - deploy: Delete .updated file from /etc and /var on new deployments
deploy: Delete .updated file from /etc and /var on new deployments
Status: RESOLVED FIXED
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-07-28 07:18 UTC by Jasper St. Pierre (not reading bugmail)
Modified: 2018-06-21 18:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Update .gitignore (792 bytes, patch)
2015-07-28 07:18 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
deploy: Delete .updated file from /etc and /var on new deployments (2.22 KB, patch)
2015-07-28 07:18 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review

Description Jasper St. Pierre (not reading bugmail) 2015-07-28 07:18:13 UTC
This is needed for systemd update integration. See patches.
Comment 1 Jasper St. Pierre (not reading bugmail) 2015-07-28 07:18:16 UTC
Created attachment 308283 [details] [review]
Update .gitignore
Comment 2 Jasper St. Pierre (not reading bugmail) 2015-07-28 07:18:19 UTC
Created attachment 308284 [details] [review]
deploy: Delete .updated file from /etc and /var on new deployments

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.

[endlessm/eos-shell#5426]
Comment 3 Colin Walters 2015-07-28 18:47:16 UTC
Review of attachment 308284 [details] [review]:

Side note: OSTree is *not* stateless, as you have persistent data in both /etc and /var by default.

Hmm.  So the systemd ConditionNeedsUpdate interaction with anything else (whether that's traditional dpkg/rpm package systems, OSTree, Docker images, whatever) is AFAIK not robustly explored - you're sort of implicitly starting that here =)

At the moment, it's just systemd-update-done.service which creates these.  We could instead say that OSTree should be in charge of this, and disable the default service.

Then instead of unlinking them, we take care of creating them.
Comment 4 Colin Walters 2015-07-28 18:47:33 UTC
Review of attachment 308283 [details] [review]:

Committed.
Comment 5 Jasper St. Pierre (not reading bugmail) 2015-07-28 20:53:00 UTC
Review of attachment 308284 [details] [review]:

The traditional /etc/.updated and such works fine with dpkg / rpm. When those install new files, the mtime of /etc is updated, but /etc/.updated is old, so systemd detects this and runs the update script. The problem here is that OSTree, the mtime is forced to 0, so the /etc/ directory is never newer than the /etc/.updated file that's migrated over.

Another way to fix it would be to save mtimes of files in the deployment. Then we would be the same as the dpkg / rpm case. But it was easier for us to just say that this is always a new /etc/ and /var/ directory at deployment time.
Comment 6 Colin Walters 2015-07-30 19:46:10 UTC
Hmm.  If dpkg/rpm update a file /etc/blah, then indeed the timestamp on /etc is updated.  But if for example a unit file in, /etc/systemd/system is updated, that doens't change the timestmap of /etc (by default).

There has been discussion of recursive timestamp updates, which would make sense for /etc I'd say, but AFAIK the code isn't in the upstream kernel.

I just tested at least with Fedora 22 (in a Docker container), and rpm does not update the timestamp on /etc when writing new files into subdirectories of /etc:

[root@9edb20e6564c /]# rm /etc/dbus-1/system.conf 
rm: remove regular file '/etc/dbus-1/system.conf'? y
[root@9edb20e6564c /]# ls -ald --time-style=full /etc
drwxr-xr-x. 45 root root 4096 2015-07-30 19:44:04.263209747 +0000 /etc
[root@9edb20e6564c /]# yum reinstall dbus
Yum command has been deprecated, redirecting to '/usr/bin/dnf reinstall dbus'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Last metadata expiration check performed 0:05:50 ago on Thu Jul 30 19:39:42 2015.
Dependencies resolved.
===================================================================================================================================================================================================================
 Package                                        Arch                                             Version                                                   Repository                                         Size
===================================================================================================================================================================================================================
Reinstalling:
 dbus                                           x86_64                                           1:1.8.18-1.fc22                                           updates                                           354 k

Transaction Summary
===================================================================================================================================================================================================================

Total download size: 354 k
Is this ok [y/N]: y
Downloading Packages:
dbus-1.8.18-1.fc22.x86_64.rpm                                                                                                                                                       79 kB/s | 354 kB     00:04    
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                               63 kB/s | 354 kB     00:05     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
warning: Unable to get systemd shutdown inhibition lock
  Reinstalling: dbus-1:1.8.18-1.fc22.x86_64                                                                                                                                                                    1/2 
  Erasing     : dbus-1:1.8.18-1.fc22.x86_64                                                                                                                                                                    2/2 
  Verifying   : dbus-1:1.8.18-1.fc22.x86_64                                                                                                                                                                    1/2 
  Verifying   : dbus-1:1.8.18-1.fc22.x86_64                                                                                                                                                                    2/2 

Reinstalled:
  dbus.x86_64 1:1.8.18-1.fc22                                                                                                                                                                                      

Complete!
[root@9edb20e6564c /]# ls -ald --time-style=full /etc
drwxr-xr-x. 45 root root 4096 2015-07-30 19:44:04.263209747 +0000 /etc
Comment 7 Colin Walters 2015-07-30 19:48:43 UTC
Obviously it wouldn't be too hard to get a patch into rpm/dpkg or whatever to do this - but to my knowledge again neither have any completely thought out integration with the systemd .updated mehcanism.
Comment 8 Cosimo Cecchi 2016-05-11 23:53:48 UTC
Colin, any chance of getting this patch in?
I think what dpkg/rpm do wrt. this is unrelated to the optimal behavior of OSTree to play well with systemd's expectations, and we've been shipping the patch for a while with no side effects.
Comment 9 Dan Nicholson 2018-06-21 18:44:21 UTC
This was closed via https://github.com/ostreedev/ostree/pull/1631.