Anurag S. Maskey wrote: > > > Stephen Hahn wrote: >> * Anurag S. Maskey <Anurag.Maskey at Sun.COM> [2009-05-04 22:33]: >> >>> NWAM Phase 1 introduces a couple of new SMF services and modifies a >>> few others. These new SMF services have dependencies between each >>> other and existing services. When system/manifest-import runs, it >>> doesn't care about the dependencies. Thus, we have a problem >>> because we want one service online before the second one starts.. >>> >>> Couple of things we have tried (let me illustrate with SMF services >>> A and B where B depends on A (in other words, A must start before >>> B)). manifest-import doesn't care if B was imported and started >>> before A. >>> >>> 1. In B's start method, explicitly enable A. If A is already >>> enabled, it does nothing. Otherwise, A is started. This doesn't >>> work (all the time) because if manifest-import hasn't imported A >>> yet, then the enable finds nothing. >>> >>> Two solutions we're looking at: >>> >>> 1. In B's start method, check if A been enabled (it will be if it >>> has been imported). If not, sleep for a while and check again. If >>> A still hasn't been enabled, exit with an error. We don't want to >>> have a loop here for fear that A may have failed and don't want B to >>> keep checking forever. >>> >>> 2. In B's start method, check if A has been enabled. If not, svccfg >>> import A. The issue here it that it may create a race condition >>> where B imports A and manifest-import is also importing A. I don't >>> see any other scripts (in /lib/svc/method) doing such imports, so >>> what would happen here? Are there any controls to make the import >>> operation exclusive? >>> >>> Is there a different solution to the problem of manifest-import >>> respecting service dependencies? >>> Other comments? >>> >> >> The problem statement mentions dependencies between A and B, but the >> discussion only talks about start method implementations. What are >> the expected dependencies between A and B, and what characteristics do >> the dependencies have? >> > >> For instance, if B requires A, then B will remain offline until A is >> online. No enabling, sleeping, etc. should be required in the start >> method. (Are you seeing other behaviour with a require dependency?) >> > SMF service B required A, and the dependencies were indirect via an > already existing SMF service C (that's also updated). I think this > caused the failure. The problem is that when manifest-import runs the > dependencies with existing services are not respected. > > In the above case, C was already online with the old manifest. Thus, > when B started, it's dependency with C was satisfied and B went online. > And, B assumed that A was already online since C is already online > (albeit with an old manifest). > > This can be solved by have B directly depend on A. > > However, there's still different a problem that still exists with > manifest-import. manifest-import doesn't import the updated manifests > in any particular order. This means that when property/property-groups > are added/removed from manifest, other services cannot assume that the > change has taken place. Again, let me try with example services and > properties: > > SMF service X already exists in the system and is online before > manifest-import runs. SMF service Y is a new service that depends on X > and is introduced by our project. Our project also added a > property-group p to service X. Service Y uses property-group p in its > start method. Now, manifest-import doesn't guarantee that the new > manifest for X is imported before Y's. If the imports happened in that > order, then there's no problem. But, if Y was imported before X, then > Y's start method will look for the property-group p and fail. :(. > There's error in /var/svc/log/Y.log saying "svccfg: property group p > doesn't exist") > > For situations like this, can Y explicitly import X's new manifest? Or, > is it better for Y to simply sleep and wait for X's new manifest to be > imported? (Y can determine whether X's new manifest has been imported > or not by checking for a property in property-group p that it know > should/will exist after the new manifest is imported.) >
If Y does not need to start prior to manifest-import, can you try define a dependency on manifest-import service for service Y? This should make service Y wait until manifest-import service completely imported all new manifests. -tony
