On Mon, Jan 5, 2009 12:45PM, nico wrote: > On Mon, Jan 05, 2009 at 09:16:28AM -0800, David > Bustos wrote: > > Quoth Richard L. Hamilton on Sat, Jan 03, 2009 at > 09:19:16AM -0800: > > > Looking at the method script for the sar service > (as of snv_97), I see that > > > it creates the sys crontab file if it doesn't > exist (for start) or deletes it unconditionally > > > (for stop), directly, without using the crontab > command. That might not work well if > > > someone enabled the service when cron was already > running (although if the file was > > > > Can you take a look at > > > http://bugs.opensolaris.org/view_bug.do?bug_id=6197324 > and see whether > > that describes the problem? If not, please file a > new bug at > > bugs.opensolaris.org . > > IMO 6197324 is a subset of the problem, and should > either be closed as a > dup of a CR covering the larger problem, or it should > be taken over to > describe the larger problem. > > ISTM that the sar cron entries should always be > created at install time > and that they should be no-ops when the service is > disabled. That is: > this is a design bug in the sar service. > > Looks like the fix should be simple though, since the > programs run by the > cron entries are shell scripts -- testing that the > sar service is online > should be easy enough, and since the cronjobs run > rarely, the impact of > this additional checking should be minimal. Perhaps > the fix is as > simple as adding this to the top of the sa1 and sa2 > scripts: > > /bin/svcs -H -o state svc:/system/sar:default | \ > /usr/xpg4/bin/grep -q online || exit 0 > > (sar depends on filesystem/minimal, so that pipeline > should work fine) > > Nico
That would address all my concerns, by keeping the sar service from manipulating the sys crontab at all. Indeed, it seems proper to me that the scripts would become no-ops with the service disabled. And until such time if any as SMF subsumes cron (like launchd on OS X), "least surprise" presumably means neither changing the way one alters the collection interval, nor clobbering (anything else in) sys crontab when the service is disabled. The only additional item I'd want would be suitable documentation changes and maybe an additional line of comment in the sys crontab file to the effect that there was no need to comment out the sa[12] script lines as the scripts would be no-ops if the service was disabled. That would IMO actually be helpful to those who enable sar collection only as needed, since they may not do it often enough to get the (pre-SMF) two-step approach right; all they'd have to do is optionally check or update the collection interval, and then enable the service, and merely disable it when no longer needed. A slight further improvement in an already elegant solution might be if svcs had an option to return 0 if a specified service was valid, online (or legacy_run), and nonzero otherwise (possibly with distinct values for invalid services or various non-running states); that would simplify and cut the overhead of this sort of check (only one process instead of two). No-ops should be cheap. I suppose other uses would be found for making that sort of test simpler. Perhaps the sa2 script could use a further change: the number of days to keep could be a property which it retrieves, rather than being hard-coded. After all, people shouldn't really be editing the script, right? :-) -- This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
