GNOME Bugzilla – Bug 752950
deploy: Delete .updated file from /etc and /var on new deployments
Last modified: 2018-06-21 18:44:59 UTC
This is needed for systemd update integration. See patches.
Created attachment 308283 [details] [review] Update .gitignore
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]
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.
Review of attachment 308283 [details] [review]: Committed.
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.
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
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.
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.
This was closed via https://github.com/ostreedev/ostree/pull/1631.