[systemd-devel] [PATCH] units: add [Install] blocks for the binfmt_misc units

[Burton, Ross]

On 6 September 2013 15:50, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Fri, Sep 06, 2013 at 03:19:47PM +0100, Ross Burton wrote:
>> If the administrator disables systemd-binfmt it can't be re-enabled correctly
>> because there is no [Install] block, the symlinks to sysinit being created at
>> install time manually.  Add an Install block so that the those symlinks can be
>> re-created using systemctl, and a dependency on the automounter in
>> systemd-binfmt.
> Idea sounds good.

falconindy/Dave Reisner on IRC claimed that because the symlinks
created by the install script are in /lib "systemctl disable" won't
actually work.  I'm doing a fresh build to verify this.  Some
background is probably useful: for embedded reasons (...) it's
entirely possible to have a systemd system where the kernel was
configured with binfmt_misc as a module but that module isn't
installed.  The result is that there's an automount on
/proc/sys/fs/binfmt_misc that when touched will attempt and fail to
mount (QA discovered this as their test script does a df, which causes
the automounter to run).

My current solution to this is to split out the systemd-binfmt pieces
into a separate package that can be installed if required, so then
we'd want to be able to enable/disable the units like normal on
package install/remove.  This means in our case, we delete the
symlinks that make install creates for binfmt-misc and instead use
systemctl enable/disable in package scripts.

>> Signed-off-by: Ross Burton <ross.burton at intel.com>
> We don't use that.

Noted.

>> +Wants=proc-sys-fs-binfmt_misc.automount
> Can you replace this by RequiresMountsFor=/proc/sys/fs/binfmt_misc ?
> That seems cleaner, and also generates better dependencies: Requires and
> After. It won't work at all without the mount, so Requires is better,
> and without After there's a race condtion.

There's already an After, but the wants/requires point is good.  There
seems to be an infinite number of options in unit files. :)

> I'd commit it with this change myself, but I don't currently have the means
> to test if everything still works.

Due to the comments I received on IRC I'm currently putting this patch
through another test, I'll send a V2 if it works.

Cheers,
Ross