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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121183453.gf15...@smurf.noris.de