I have hope that this discussion can end in agreement on the issue raised in #156161. Toward that end I offer the following interpretation of what has been said and finally ask whether we can agree to implement the reinterpreted #156161.
The original question was about how to prevent services from being started. Some packages employ a mechanism (a flag file, or an environment variable set it in an /etc/default/ file) other than the standard "rc" mechanism for switching services on and off. The blunt reply to this was: Don't do that. The standard mechanism for enabling and disabling services in runlevels is update-rc.d, so please use that. This answer is basically right. If I run "/etc/init.d/foo start" then foo should start. We have to accept, however, that people want, in addition to the rc system, a simple way globally to enable and disable a given service. One reason is that if one decides to disable a service by setting all its rc?.d symlinks to K then he loses the infor- mation about what those symlinks should be named when the service is reënabled. Such a mechanism has been wished for in #67095 and #123446 among other places. Perhaps those wishes should be fulfilled and something should be written to make it easy for the admin to disable and enable a service without destroying the rc symlink farm information. Such a utility would use update-rc.d to make changes (as required by policy) but would remember how things were set up before the service was disabled so that the former situation could be easily restored. Whether and how that wish is granted is not my main concern here. What I would like to know is whether we can agree to enhance the rc system by defining what happens when there is neither a start nor a stop symlink for a service in a given runlevel. Henrique de Moraes Holschuh and I discussed this point earlier but we didn't see eye to eye because we were approaching it with different assumptions about what the right behavior is. HdMH assumed that all services are supposed to be controlled by the rc system which requires that there be either an S or a K symlink for each service in every runlevel directory. If there is neither an S nor a K symlink for a service in a particular directory then this is operator error and the behavior of the system is "undefined". It follows that it isn't a bug that invoke-rc.d starts the service. I was approaching the issue under the assumption that if there is neither an S nor a K symlink for a service in a particular runlevel directory then that means that the rc system should not change the state of the service but should leave a running service running and a stopped service stopped. #156161 was originally rated as a bug report based on this assumption. Bug #197858 was also submitted based on that assumption. I am now willing to grant that HdMH is right and that _currently_ the behavior of the rc system is not defined if there is neither an S nor a K symlink for a service in a given runlevel directory. My proposal is that the behavior of the rc system _be_ defined such that it works the way I assumed it was supposed to work, i.e., such that if there is neither an S nor a K symlink for a service in a particular runlevel directory then that service is to be neither started nor stopped on entering that runlevel. The advantage this specification would have is that it would allow maintainers to install services and initscripts that are not by default under the control of the rc system but under the control of the administrator, who can run the initscript with "start" and "stop" arguments. Changing runlevel would neither start nor stop these services unless the administrator chose to put the service under the control of the rc system by setting up symlinks in the runlevel directories. The absence of S and K symlinks would mean "manual". If a utility was written to make it more convenient to disable and enable a service, as discussed above, then one could add a "manual" state (no symlinks) to the "disabled" (all K symlinks) and "enabled" (not all K symlinks) states. I have downgraded #156161 to a wish that the rc system be specified in this way. Can we agree that this a good idea? If not, I would be interested to know where the problems lie. -- Thomas Hood
