If I have a script that "provides" something in /etc/init.d and in my runlevel I have the script itself, the provide will be pulled even if its not needed.. Example: I hate scripts a, a2 and b. a is normal a2 provides a b needs a I have runlevel runa2b and runab runab contains a and b runa2b contains a2 and b I would expect that in each case only the scripts currently in the runlevel would be called. In the current situation is it true for a2b, but not for ab. In the ab case, all three scripts are called. We use that for adelie scripts in combination with the new patches in bug 4151 so we can remplace checkroot with a custom script in the nodeboot runlevel (that custom script does the equivalent of init_node()). But that custom script also gets called on the server.... Reproducible: Always Steps to Reproduce:
Alright, provide can't override real scripts now... Anyways, our problem is with a critical script (ie we replace checkroot with a nfsroot script for our nfsroot systems). We are doing something different now (have a boot script, but not critical that marks checkroot/hostname as started)
We need to sort something out for adelie, but I need the full specifics. Anyhow, my mail is down (again), so that is why I might have not replied .. could you please be more specific with how you want to do things, and why? Thanks.
With the new init-script, we have changed the way we do that.. We have one script in the "critical scripts" which replaces checkroot/hostname/modules, it basicly does what the init_node() function did previously. And we have a second script that just mark_service_started hostname, checkroot, modules.... This uses our configurable boot level so the adelie nodes use a different boot level from the server (ie checkroot is never run on the nodes). The provide is no longer revelevant since it seems that the dependancy tree no longer depends on the runlevels. The solution to this problem is also in our latest patches on bug 4151.
Marking this as dup of bug #4151, although not really. *** This bug has been marked as a duplicate of 4151 ***
