control: tags -1 +wontfix +moreinfo
[2019-04-11 10:54] Jesse Smith <[email protected]> > >> When update-rc.d calls insserv, the rcN.d directories are rebuilt > >> without taking into consideration any adjustment that might have > >> been set up locally. That seems to be done on the assumption that > >> the dependencies coded in the LSB blocks are universally accurate. > >> Now, LSBs are a great improvement over numeric priorities, but to > >> hamper local system tuning, which is not necessarily related to > >> LSBs, IMHO is an insult to the legendary versatility of SysV init. > > > > I believe it is not how things work now. Last time I checked, call > > `insserv foo` does not update any links to `foo' if there is already at > > least one of them. > > > > @Jesse, am I right? > > I just ran a quick test and can confirm that if I have an existing link > to a service, for example /etc/rc5.d/S05bluetooth, then running the > command "insserv bluetooth" will attempt to remove the old symlink and > replace it with one that conforms to the LSB headers. In my case, > removing the original link and creating /etc/rc5.d/S04bluetooth. > > Now, as to whether this should be considered a bug or a desired effect > is open to debate. On the one hand it is understandable people might not > want insserv to overwrite their changes. On the other hand, in my case > insserv is fixing a mistake in my symlinks, and adjusting them to match > their LSB headers. > > My thought on this is if someone wants to improve their start-up routine > it makes more sense for them to edit their script's LSB header and > re-run insserv rather than editing links by hand. Thank you Jesse. Sounds reasonable. Dear submitter, please consider, whether your issue could be solved by editing LSB headers and if not, why. So far, tagging as wontfix and moreinfo, subject to close-on-timeout. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
