[OpenAFS] Proposed changes for server log rotation

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEEACA06A913BCB9F07D6439E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12/3/2010 5:25 PM, Steve Simmons wrote:

> On Dec 3, 2010, at 10:38 AM, Jeffrey Altman wrote:
>=20
>> At the very least I believe that we need to implement an internal log
>> rollover mechanism based on either max size or max time with a max
>> number of old logs to be maintained.  Implementing this should not be
>> overly complicated if we agree that this internal file logging is not
>> meant to replace full featured log rotation tool chains.
>=20
>=20
> Sorry, Jeff, but I must disagree strongly with 'with a max number of ol=
d logs to be maintained.' That's the sort of thing that's best managed wi=
th an external tool to do those sorts of renames, what naming strategy to=
 use, etc.

The problem that I am attempting to address with that requirement is
disks filling on machines that are much less managed then your environmen=
t.

> I even mildly disagree with 'internal log rollover mechanism based on e=
ither max size or max time.' My desire for better AFS logfile rotation is=
n't based on a problem with them getting too big. Mine is partly based on=
 AFS' predeliction for renaming files to '.old' and thereby wiping out lo=
g files when you get multiple restarts close together, and partly on the =
inability to sanely rotate and archive those files without having to rest=
art AFS (and yes, I now see that some of that can be done semi-automagica=
lly). Having the individual files get too big is simply not an issue for =
us. If others' milage varies, they should speak up. But in general, all t=
he right tools exist (logfile watchers and renamers) to do that job. I do=
n't think we should try and build such into AFS.

OpenAFS is not just used in large organizations and it needs to be easy
to deploy for small home/business deployments without requiring that
there be a dedicated logging infrastructure.

> In summary, all the really significant problems with AFS log files are =
solved by a close/reopen on HUP or other signal we choose. It's an simple=
 solution, it dovetails very nicely with existing tools and with relative=
ly simple cron scripts, "it's the UNIX way", and it's probably easy to im=
plement. It doesn't break 'bos *log*', either. It's a win.

Ah yes "the Unix way".  OpenAFS is not a Unix only distributed file
system.  It was specifically designed to be cross platform and while
there are no functioning Windows based servers in deployment at the
moment from OpenAFS, a significant amount of effort has been put into
making that be a possibility in the near future.

OpenAFS needs to work well on Unix.  To that extent I agree that the
default logging option on Unix should be syslog.  However, for those
sites that prefer to work with the existing file based logs or for
platforms that do not have syslog, we need to have a solution that does
not result in the disk becoming full as a result of the user failing to
delete all old files.

> The problem with .old logs getting overwritten when a restart occurs is=
 one I can fix in cron venues. Mind you, with log open/close on hup I see=
 no need for the 'feature' of renaming FooLog to FooLog.old on any restar=
t. Instead we should just keep appending to the  existing logfile if it's=
 already there.




--------------enigEEACA06A913BCB9F07D6439E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJM+o97AAoJENxm1CNJffh4deIIAMc00wUxRxpOAZgavMjEcUpv
5xVoLzyNRne9BUrd1GPjzrZjHRCzsGNpTRb1wrM7OxjUp6UlqzWr6GUtdGVg/Lbg
cQ3zZkpcRTgbk0UmNJK+8tQvNko4MsXE+Za88q1sxxcTI2fIun0Mwp1d8ZWmZxxU
1Y7dfEOvHxQOQMW7mr6ZEjUDTie1NOxk4q7aTokgHnGwO5DecXH8G9ycvlUYOAdP
79R8JbxuGnHRtAOYjxxjCQz45H6nigWfQX1FhgpGHPGG+BmutV8yLnZQLNXt9bxE
kBktOMZMfTdr972fxIQb/+tzymp1tllGFN+KarKCVlCdUdONbFLM3Qx0dwemTTc=
=+lDy
-----END PGP SIGNATURE-----

--------------enigEEACA06A913BCB9F07D6439E--