[systemd-devel] [systemd] Add dbxtool to 90-default.present.

[Peter Jones]

On Fri, Feb 20, 2015 at 05:32:44AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > dbxtools.service declares itself both before basic.target, and also
> > > after basic.target (It has the default DefaultDependencies=yes, which
> > > adds a dependency on basic.target automatically. It declares itself as
> > > a dependency of basic.target).
> > 
> > The man page seems to say that Requires= (as provided by
> > DefaultDependencies=yes ) doesn't imply either before /or/
> > after.  Nevertheless this is worth reconsidering given what you've made
> > me notice below.
> systemd.unit(5) says "For example, for service units, these
> dependencies ensure that the service is started only after basic
> system initialization is completed". It doesn't say anything about specifically
> about Requires. This is on purpose, because those semantics ale a bit fluid.

I was referring to:

    Note that requirement dependencies do not influence the order in
    which services are started or stopped.  This has to be configured
    independently with the After= or Before= options. If a unit
    foo.service requires a unit bar.service as configured with Requires=
    and no ordering is configured with After= or Before=, then both
    units will be started simultaneously and without any delay between
    them if foo.service is activated.

Honestly it doesn't make much difference to me - as long as a) it's
after the efivars fs is mounted and b) it does actually happen some time
during boot, then the ordering makes /no/ difference.

> > So right now I've got this:
> > -------------------------------------------------------
> > [Unit]
> > Description=Secure Boot DBX updater
> > RequiresMountsFor=/usr/bin/ /usr/share/dbxtool/
> Running services before /usr is mounted is not supported (outside of
> the initramfs). So this should not have any effect.
> 
> > After=sys-firmware-efi-efivars.mount
> > Requires=sys-firmware-efi-efivars.mount
> I don't have an EFI system at hand to test this, but I dont' think .mount
> units are created for api mount points. Does this actually work?

There's a unit file sitting on the filesystem - what do you mean you
don't think mount units are created?  (I can't test thoroughly right now but it
looked superficially like it worked yesterday...  I'll try it again
and watch carefully before Monday's deadline.)

> Would you mind sending this unit to systemd-devel? Early boot units are
> notoriously hard to get right.

Sure, I'll Cc: them here. 

For those just joining in, I've got a one-shot unit that needs to run on
every boot to guarantee some firmware state is correct.  It needs to run
after /sys/firmware/efi/efivars is mounted.  There has been some
question as to what the best way to accomplish that is.  For clarity,
what I've got after Zbigniew's and Harald's suggestions is:

-------------------------------------------------------
[Unit]
Description=Secure Boot DBX updater
After=local-fs.target
After=sys-firmware-efi-efivars.mount
ConditionPathExists=/sys/firmware/efi/efivars

[Install]
WantedBy=basic.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/
-------------------------------------------------------

Would RequiresMountsFor=/sys/firmware/efi/efivars be better?  Will it
actually work, or will it just put it after /sys is mounted?  All
suggestions welcome.

-- 
        Peter