Re: init system policy
Hi,
Philip Hands:
> Is there any way this isn't going to be an enormous surprise to people
> that are used to the way that Debian usually treats /etc?
>
Well, instead of "edit /etc/default/FOO and search for the flag to disable
the daemon" or the programmatic equivalent of "add a bunch of symlinks
named K* to /etc/rc*" you run "systemd mask SERVICE", which translates to
"add one symlink to /dev/null at /etc/systemd/system/SERVICE".
This is discoverable if you read the systemctl manpage. Granted, that
page is somewhat longer than the one for invoke- and update-rc.d, but
OTOH systemctl can do a bit more than these.
I do wonder, reading these manpages, whether the enable/disable/mask
subcommands could do with somewhat clearer text in that manpage, but I'm
the wrong person to work on that – at least if the goal is to actually
_improve_ their clarity. :-/
> It seems that you're saying that throwing links in and out of /etc is
> the way one turns things on and off, and that to actually disable them
> one needs to symlink them to /dev/null.
>
That's what systemctl ends up doing, not what you should do manually.
> I suppose we can hope that most of them never start an xterm let alone
> look at their init, but I'd expect some people to be pretty upset by
> this, which is going to result in another round of, erm, fun.
>
Personally I'm much more upset when I tell the init system that starting my
app servers should depend on a running postgres which in turn should only
start when the database disks get mounted, and that doesn't happen.
--
-- Matthias Urlichs
Reply to: