Erwan David wrote: > Bob Proulx a écrit : > >Am I completely misunderstanding the documentation on this? Maybe. > >If so then I am sorry for misleading you along with me. I am > >researching the problem. I think this is completely against the > >documented interface. > > I added some traces in my policy-rc.d (to a file in /root), and got > the following resullt : > boot does not use it (should be startpar), /sbin/service does not > use it, only invoke-rc.d, which seems to be only used in postinst > for restarting a service. You are correct. I was completely wrong about this. Sorry. I couldn't find a plausible connection when I dug through the scripts. Confused I wrote to the pkg-sysvinit-devel team yesterday and got that answer as a response this morning! So apparently policy-rc.d controls the policy to init.d. I think it is misnamed. It should have been policy-init.d instead. It doesn't control policy of the rc?.d scripts. Apparently the *only* purpose is for use in chroots. Chroots get all of the package installations and upgrades. The policy-rc.d controls access to the init.d scripts instead of having a package postinst calling '/etc/init.d/foo restart' or 'service foo restart' directly. Since a chroot doesn't normally get its own init nor have its own runlevels they aren't ever changed there and so there wasn't a need to include /etc/init.d/rc in the policy infrastructure. And so using it for a real system has no effect at all. I apologize for leading you astray on this topic and wasting a lot of your time. I can only offer that I was also led astray. Sometimes documentation can be terribly misleading. > My solution for the moment is to disable those services (thus losing > the information about their starting order) through update-rc.d > disable (which also means each upgrade will now get polluted by > messages saying their start runlevel are different from default) and > starting them from my encrypted partition mounting script. I think you have made the best of the situation. As far as losing the starting order that doesn't matter at all. The 'insserv' program dynamically sets that up based upon the LSB headers of the enabled scripts. If you were to return those back to being enabled then insserv would order them according to the current set of enabled scripts. So no real information is lost. It isn't like the prior release with static legacy hard numbered ordering. Again let me apologize. Sorry for the diversion down the rabbit hole. Bob
Attachment:
signature.asc
Description: Digital signature