[Bug 1942056] Re: /etc/cron.monthly/acct fails if wtmp not rolled monthly

[Shane Williams]

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to acct in Ubuntu.
https://bugs.launchpad.net/bugs/1942056

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

Status in acct package in Ubuntu:
  Confirmed
Status in acct package in Debian:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/acct/+bug/1942056/+subscriptions