Re: better make a standard for /etc/*/*_not_to_be_run
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
Reply to: