On Fri, Sep 6, 2013 at 5:32 PM, Burton, Ross <[email protected]> wrote: > On 6 September 2013 15:50, Zbigniew Jędrzejewski-Szmek > <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
