Description of problem:
/etc/raddb/modules/radutmp says that "radutmp it's not a log file, so it doesn't need rotating."
However it is configured to rotate in /etc/logrotate.d/radiusd
Version-Release number of selected component (if applicable):
Also reported upstream, since it also provides redhat packaging:
See also upstream debian logrotate:
Problem is closed upstream with this commit:
Why remove just radutmp from rotation, why not also remove radwtmp? Aren't the issues identical?
# Write a 'utmp' style file, of which users are currently
# logged in, and where they've logged in from.
# This file is used mainly for Simultaneous-Use checking,
# and also 'radwho', to see who's currently logged in.
# Where the file is stored. It's not a log file,
# so it doesn't need rotating.
# The only use for 'radlast'. If you don't use
# 'radlast', then you can comment out this item.
# Note that the radwtmp file may get large! You should
# rotate it (cp /dev/null radwtmp), or just not use it.
radutmp is a "live" file of currrently logged users, radwtmp keeps a log of ever user login.
Sorry but you didn't answer the question, I know the difference between the two files. Upstream does not rotate radutmp or radwtmp, nor does debian. The reason for not rotating radwtmp seems identical for not rotating radutmp. If such a change were pushed into RHEL then I would be included to remove both radwtmp and radutmp from the log rotation script and not just one. Do you perceive any reason not to remove both?
BTW, although these are not log files there have been complaints in the past about these files growing excessively large. Hence the reason they are rotated.
Is your complaint based simply on the fact they are not log files, or is there a specific reason the rotation is creating a problem?
There needs to be a specific reason for this change in behaviour in a shipped component.
(In reply to comment #5)
> Sorry but you didn't answer the question, I know the difference between the
> two files.
Probably you didn't read carefully what I quoted from the config files in my previous post. Maybe I wasn't very clear that the first part was about radutmp, the second about radwtmp. What they say is very clear.
> Upstream does not rotate radutmp or radwtmp, nor does debian. The
Red Hat upstream rotate radwtmp but (now, after my patch get committed) don't rotate radutmp:
> reason for not rotating radwtmp seems identical for not rotating radutmp. If
> such a change were pushed into RHEL then I would be included to remove both
> radwtmp and radutmp from the log rotation script and not just one. Do you
> perceive any reason not to remove both?
Yes, as I quoted in the previous post. radwtmp is a log file and will always grow. radutmp is not a log file, its size grows and shrinks based on current users and anyway it's always relatively small in size (few KB for me).
> BTW, although these are not log files there have been complaints in the past
> about these files growing excessively large. Hence the reason they are
> Is your complaint based simply on the fact they are not log files, or is
> there a specific reason the rotation is creating a problem?
> There needs to be a specific reason for this change in behaviour in a
> shipped component.
There is really no need to rotate radutmp, it's a DB of current logged users, as there is no need to rotate a mysql DB.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.
Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.