Hi Henrique,
Henrique de Moraes Holschuh wrote:
I recall there was a logic line in invoke-rc.d we could invert, so that when
the target state is unknown (i.e. user did the wrong thing and REMOVED the
links instead of using K links) we would assume the service is disabled
instead of enabled.
As far as I can see, the issue here are incorrect user expectations.
If you do not want the services to start from init.d/rc during boot,
you need to disable the services by changing the S* symlinks to K*
symlinks. Removing the symlinks is not going to work the way you want
it. Disabling
Petter Reinholdtsen wrote:
Removing the symlinks send you into undefined invoke-rc.d territory,
and thus you can expect anything, even a restarted service. :)
Understood. My request is to define it. Undefined behavior is a
bad thing in computing.
Whats about all the services in /etc/init.d
[Harald Dunkel]
Whats about all the services in /etc/init.d defining a S or K
link for just a subset of all run levels? Are these packages broken?
I suspect it depends, but packages failing to define if the service
should be enabled or disabled in runlevel 1-5 are most likely broken.
Most
On Thu, 27 Aug 2009, Harald Dunkel wrote:
I would suggest to take a look at the LSB-style headers of
the run level scripts in /etc/init.d . Many do not define
symlinks for all run levels. udev (just as an example) only
defines a symlink for S. This is surely not a user error.
It also mean we
On Fri, 21 Aug 2009, Petter Reinholdtsen wrote:
I have disabled several services using insserv -r, e.g.
Eh, that is not the supported way to disable services. The start
symlinks should be changed to stop symlinks to disable a service the
supported way. Try something like this instead (or
6 matches
Mail list logo
