On Mon, 17 Nov 2014, Anthony Towns wrote: > On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote: > > On Mon, 17 Nov 2014, Anthony Towns wrote: > > > If deb-systemd-* were to get merged in, it might be worth doing a name > > > change at the same time, I guess. Changing either before jessie doesn't > > > seem remotely plausible. > > > > > > I wonder if it would make sense to just merge it all into the "service" > > > command; ie: > > > > > > # service --use-policy ssh start > > > # service --use-policy ssh restart > > > # service ssh enable > > > # service acpid.socket mask-for-upgrade > > > > "service" is an user interface, while deb-systemd-*, invoke-rc.d, and > > update-rc.d are first and foremost to be used by a package's maintainer > > scripts (postinst, etc). They have different design goals. > > My understanding is that update-rc.d is the recommended way for admins > to enable/disable services. Is that incorrect? (It's what I've documented > in my proposed init guide/policy)
I don't think anyone ever wrote an initsystem-agnostic user interface for this, so people have been using update-rc.d. It caused a lot of problems before we forced the use of "insserv". But I could easily be wrong about this. > Obvious alternative idea, provide a maintainer script oriented tool > under a different name: > > service-maintscript ssh start > service-maintscript ssh enable > service-maintscript acpid.socket mask-for-upgrade I have nothing against "service-maintscript", although "service-debmaintscript" is likely safer since we are not likely to make any effort to make it usable by SuSE, RedHat, Gentoo, etc. > But if we did that how would we recommend admins enable/disable > services? Just use the native stuff (rm /etc/rc?.d/S*ssh; systemctl > disable ssh)? Maybe extend "service"... BTW, neither rm /etc/rc?.d/S*ssh nor "systemctl disable" will do the right thing: both have pitfalls. "No link" is an undefined state for sysvinit rc when a runlevel switch happens (the correct way to disable something is to have a K link in all normal runlevels), and "systemctl disable" does not block socket activation automatically (refer to Debian bug #736258). > > IMHO it is best that we keep system interfaces separate from user interfaces > > like "service", > > Yeah, I see where you're coming from. My intuition goes the other way; > that it's better to have a single tool for both uses if that's feasible. > We don't have anything special for doing cron jobs via packages compared > to what admins might do to add a cron job, eg. Maybe that's a bad > intuition though. The "package maintainer mode" interfaces expose a lot of user-unfriendly details which are easy to misuse *and* which are not going to be changed to become more userfriendly once in the field, since the "package maintainer mode" must NEVER break the backwards-compatibility of the ABI. > BTW, it occured to me that it seems like a wart that update-rc.d doesn't > respect policy-rc.d -- as it stands, policy-rc.d can prevent a service > from (re)starting during install/upgrade, but it'll still start on the > next boot. Is that just something that never got thought of / done, > or does it actually make sense? policy-rc.d is an internal detail of the invoke-rc.d policy layer, which was designed only with package maintainer scripts starting or stopping services during install/upgrades/downgrades/removal in mind. It was not meant to be used for anything else. Therefore, policy-rc.d was never designed to set policy when administratively enabling or disabling services. We could extend policy-rc.d to be usable also by update-rc.d, but I would not go there unless there is an important usecase for this that is related to maintainer script use of update-rc.d. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20141117174741.gc24...@khazad-dum.debian.net
