[systemd-devel] Running packagekitd on shutdown

[Lennart Poettering]

On Wed, 24.08.11 02:04, Lennart Poettering (lennart at poettering.net) wrote:

> However, there are a couple of caveats: since the generators are called
> very very early at boot /var might not be around yet. So maybe the
> upgrade packs should be placed somewhere in the rootfs (or in /boot?
> that might be a good idea actually if it fits...). Split-off /var is
> nothing we can get rid of, and makes a lot of sense to support.

So, Kay and I discussed this a bit, and so here's what we'd like to suggest:

Place the actual upgrade packs in /var/lib/something/, and use a touch
file in the root dir to for the next reboot
(i.e. in style of /forcefsck and so so). That way we know from the
earliest moment of boot where we have to boot into, but we don't have to
place the large upgrade packs in the root fs. 

That means if PK wants to prepare for an upgrade it would just place the
upgrade pack in /var/lib/something/ and touch /upgrade and that's it.

The generator would then be even simpler:

if (access("/upgrade", F_OK) >= 0) {
        asprintf(&dest, "%s/default.target", argv[1]);
        symlink("/lib/systemd/system/upgrade.target", dest);
        free(dest);
}

(plus some error checking...)

Generators get the path where they should place their generated unit
configuration in as argv[1], hence the asprintf(). 

And we'd then like to ask you to place a tmpfiles fragment in
/usr/lib/tmpfiles.d/ which includes the following line:

r /upgrade

That way we can be sure that the flag file is removed as soon as the
root fs is writable.

The rest of the earlier suggestion would stay the same.

> Done!
> 
> I wonder if we should standardize step #2 in systemd itself, so that
> this becomes a well known target or so. So that other folks can use that
> too, for example if people use scripted upgrades or so (this usecase has
> come up before on the ML, so maybe we should standardize this...). Or
> maybe we shouldn't standardize this since only a recovery partition is
> the correct way to handle this.

So, we want to make clear that any kind of solution that does not use a
proper recovery partition is merely a stop gap in our eyes. And due to
that it probably makes little sense to standardize upgrade.target in
systemd. It should hence be shipped along with PK.

I think the approach outlined above is probably a good solution if you
need something quickly. However, I'd urge your experimenting with this
first before pushing this into the distros. The furture should be a
recovery partition, not upgrades from within.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.