I was looking over etc/periodic/daily/310.accounting on a system that is
very tight on space in /var, and I think that at minimum there is a
race, and at best there is a pretty serious inefficiency.
Right now after rotating the old logs the script does this:
cp -pf acct acct.0 || rc=3
sa -s $daily_accounting_flags || rc=3
case "$daily_accounting_compress" in
[Yy][Ee][Ss])
gzip -f acct.0 || rc=3;;
esac
To start with, the cp is a problem on a space-constrained system
especially when the log is very large. However I think that doing it
this way also introduces a race where events that are logged between the
cp and the sa run are not backed up in acct.0. ITSM that the proper
procedure is:
mv acct acct.0 || rc=3
case "$daily_accounting_compress" in
[Yy][Ee][Ss])
gzip --keep -f acct.0 || rc=3;;
esac
sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3
Can anyone see why that would be wrong? If there is no objection, I'll
be committing the attached patch.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Index: 310.accounting
===================================================================
--- 310.accounting (revision 218864)
+++ 310.accounting (working copy)
@@ -41,13 +41,15 @@
m=$n
n=$(($n - 1))
done
- cp -pf acct acct.0 || rc=3
- sa -s $daily_accounting_flags || rc=3
+ mv acct acct.0 || rc=3
+
case "$daily_accounting_compress" in
[Yy][Ee][Ss])
- gzip -f acct.0 || rc=3;;
+ gzip --keep -f acct.0 || rc=3;;
esac
+
+ sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3
fi;;
*) rc=0;;
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
