Public bug reported:
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
** Affects: acct (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal third-party-packages
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942056
Title:
/etc/cron.monthly/acct fails if wtmp not rolled monthly
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/acct/+bug/1942056/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
