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

[Tom Gundersen]

On Fri, Sep 6, 2013 at 5:32 PM, Burton, Ross <ross.burton at intel.com> wrote:
> 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.

Just for posterity, I suggested on IRC that you could simply ship the
symlink in the same package as the binary. This would mean that the
service is enabled if and only if the binary is installed and should
avoid the need for any enable/disable at package install/remove time.

Cheers,

Tom