Seems to me that it would avoid other problems if accton(1m) returned zero in the case of acct(2) on a non-NULL argument failing with EBUSY. Specifically, it would no longer matter if two instances of turnacct on ran at the same time.
A possible way to do what I'm talking about is contained in the attached patch. I don't see anything in the man page for accton that would preclude such a change. There stil does appear to be the possibility for mischief if ckpacct and runacct run at the same time; two ckpacct should be ok (lock file in there now), but runacct doesn't use the same lock file. And IMO, turnacct switch is what should really be using a lock file (and checking that it wasn't stale, and if it wasn't, the one that didn't get the lock should sleep and recheck and then just exit without doing anything once the lock file went away, on the assumption that the other instance did the job). Taken together, those changes might prevent some common accounting failures. But someone really ought to give the entire set of standard accounting tools a thorough once-over, IMO. Yes, I know extended accounting exists, but as long as basic accounting remains, it should still be more reliable than it has been in the past. FWIW, I haven't run accounting on Solaris 10 enough to see if it still has some of the problems like ckpacct/runacct collisions that were around since at least 2.6 (and still around in Solaris 8). But the scripts look to me like they still have the potential for some of the problems. This message posted from opensolaris.org
accton.patch
Description: Binary data
_______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
