/etc/cron.monthly/acct fails if wtmp not rolled monthly

[Ian! D. Allen]

The /etc/cron.monthly/acct cron script is run monthly by cron or anacron
to "perform monthly login accounting" with the /var/log/wtmp file.

The cron script only works correctly if the wtmp file is rolled exactly
monthly and gives errors otherwise. Fixing the script to do monthly
accounting on a wtmp file that is rolled on a schedule other than monthly
is non-trivial, because as written, the cron script makes three invalid
assumptions:

1. That accounting is rolled over exactly monthly.

The actual number of days of account data being saved before rolling is
settable by the local sysadmin. It could be any number of days, not only
a month. If the number of days is shorter than a month, the cron script
will lose data and incorrectly under-report the monthly login accounting.
If the number of days is longer than a month, the cron script incorrectly
looks for the data in the rolled file name wtmp.1 or wtmp.1.gz instead
of in the actual wtmp file where it is still accumulating.

2. That the rolled accounting file is present as wtmp.1 or wtmp.1.gz

If the number of days of account data being saved before rolling is
longer than a month, then the file doesn't roll over on every month end
and on a new system no rolled wtmp.1 or wtmp.1.gz file may exist when
the cron script runs and an error is generated about the missing file:

    From: Anacron
    Subject: Anacron job 'cron.monthly'
    /etc/cron.monthly/acct:
    couldn't open file '': No such file or directory
    last: cannot open : No such file or directory

The data is still accumulating in the /var/log/wtmp file and that is
where the cron script must look.

3. That only one month of accounting data is in the wtmp.1 or wtmp.1.gz file.

The cron script assumes that only one exact month of accounting data are
saved in the rotated wtmp.1 or wtmp.1.gz file, because the cron script
processes the whole rotated file with no date range. if log rolling is
longer one month (e.g. one year), then the current month's accounting data
will usually still be accumulating in the wtmp file, not in the wtmp.1 or
wtmp.1.gz file, and if the wtmp.1 or wtmp.1.gz file exists it will contain
more than a month worth of accounting (e.g. part or all of a year).
A begin and end date must be used to extract just the current month, and
the correct file name wtmp or wtmp.1 or wtmp.1.gz must be used to do it.

Fixing the above three problems in the cron script is non-trivial because
it will involve knowing the frequency of log rotation and then determining
whether the current month of accounting data are in the wtmp, wtmp.1,
or wtmp.1.gz files (or a combination, if log rolling is more frequent
than monthly) and using date ranges to extract just the current month.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: acct 6.6.4-2
ProcVersionSignature: Ubuntu 5.8.0-63.71~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-63-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sun Aug 29 18:15:12 2021
EcryptfsInUse: Yes
InstallationDate: Installed on 2020-10-07 (326 days ago)
InstallationMedia: Lubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
SourcePackage: acct
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.default.acct: 2021-07-18T04:14:33.822817

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Shane Williams (shanew)]

It looks to me like part of the reason this is more apparent in Focal is that /etc/logrotate.d/wtmp now contains the option "minsize 1M", whereas Bionic did not include a minsize setting (in /etc/logrotate.conf, where wtmp was handled before). All the same issues are present in Bionic, they just aren't as obvious since the wtmp is actually rotated monthly by default.

I think all the issues raised by Ian could be solved by moving the script that creates wtmp.report out of cron.monthly, and instead call the script in a postrotate option set in /etc/logrotate.d/wtmp