hi David > So you're saying that routing-setup is imported by manifest-import and > immediately started, and routeadm -u tries to set properties in other > routing services, but if manifest-import hasn't reached those other > routing service manifests yet, then the services won't exist in the > repository and routeadm -u will fail?
exactly. what seems to happen is that the forwarding services are not yet there, so "routeadm -u" fails to update their states and exits. so routeadm doesn't get to the point of setting the correct states for the routing services that should be enabled by the "routeadm -u" call. > Well manifest-import should always be enabled, so routing-setup would > always wait for it. Does routing-setup actually install routes? it does install the static routes specified in /etc/inet/static_routes, and sets the state of routing daemons appropriately on upgrade (in the particular case, network/routing/route was not enabled, and it - in.routed - was obtaining routes for the system). routing daemon services depend on routing-setup to ensure they do not run prior to it. > When were routes available before your changes? network/initial did the /etc/inet/static_routes installation and fired off "routeadm -u" (which simply forked the daemon programs in the past). i guess my concern is that there would be a lot of times that routing-setup would be waiting for unrelated services to be imported by manifest-import. i suppose the start method for routing-setup could delete the dependency on manifest-import when it runs, so the dependency would only exist the first time routing-setup is imported, but there might be cases in the future (say when a routing daemon manifest is updated but routing-setup isn't, meaning routing-setup wouldn't wait for the import of the new service before trying to interact with it) that might still cause problems on upgrade. alan This message posted from opensolaris.org
