Maybe I should be more clear. I don't see any bug in SMF. I do see an issue in the way PSARC 2007/414 for the iscsitgt service was introduced -- it could have then introduced a postinstall script (I think) to do the steps I am discussing today. But even then, I am not sure there is a bug that should be turned into a CR. Here are the details. If you see a CR in the following I am happy to file one.
When PSARC 2007/414 was integrated, it required that the iscsitgt service would run with the proc_setid privilege. A new copy of the manifest /var/svc/manifest/system/iscsi_target.xml was introduced that gave the service that privilege. The method of updating the system to the new bits always involved doing a pkgrm followed by a pkgadd. This always caused the new manifest to be imported, so the service always started up with the correct privilege. But now, PSARC 2007/414 is being ported back to S10. In this case, the code will be installed by patchadd, which does not remove the manifest and reimport it. So the observed symptom is that the iscsitgt service fails to start. And my proposed "fix" is to introduce a postinstall script as part of the SUNWiscsitgtu package, in S10 only. The postinstall script detects if the start/privileges property for the iscsitgt service is lacking the proc_setid privilege. If so, it "knows" that the boot environment being installed into does not have a current version of the above-mentioned manifest, so it re-imports the manifest. That postinstall process must run correctly whether the patchadd is being done either to a live boot environment (with no reboot) or to an alternate boot environment (e.g. by luupgrade -t). So we want to make use of the /var/svc/profile/upgrade mechanism to cause the correct import to happen later when the system is activated/rebooted. (One minor wrinkle is that when this patch is created as a test IDR, I have to manually insert the correct sections of the postinstall script from my SUNWiscsitgtu package into the IDR's own postinstall script. As far as I can tell is the way IDR postinstall scripts are designed to work.) Given this longer description (many of the details of which got fleshed out in the last few days since my original query) do you have any additional comments or requests? I have a contract request outstanding to the contract manager for the /var/svc/profile/upgrade mechanism so I can use it. I have implemented all of the above and it seems to work. Comments? Peter David Bustos wrote: > Quoth Peter Cudhea on Thu, Nov 13, 2008 at 12:09:48PM -0500: > >> I don't think there is a bug to file. I think the workaround is >> required in this case. Thanks. >> > > If there isn't a bug, then your workaround is not a workaround. Please > file a bug. > > > David >
