Folder /var/spool/anacrom is excluded from Restores by Timeshift in Mint 19 causing anacron.service to fail

[pdcurtis]

/var/spool/anacrom seems to be needed by anacron to hold files called cron.daily, cron.weekly and cron.monthly which contain the date they were last run. The folder is missing on both of my machines running Mint 19. The result is that anacron.service fails as there is no folder to access.

The syslog showed:

....
Aug 26 14:00:18 defiant systemd[1]: Started Run anacron jobs.
Aug 26 14:00:18 defiant anacron[5859]: Can't chdir to /var/spool/anacron: No such file or directory
Aug 26 14:00:18 defiant anacron[5859]: anacron: Can't chdir to /var/spool/anacron: No such file or directory
Aug 26 14:00:18 defiant systemd[1]: anacron.service: Main process exited, code=exited, status=1/FAILURE
Aug 26 14:00:18 defiant systemd[1]: anacron.service: Failed with result 'exit-code'.
...

The result is that anacron does not run and logrotate is not called and the log files gradually fill up which is how I discovered the problem.

I created /var/spool/anacron by sudo mkdir /var/spool/anacron after which syslog showed anacron running and the cron jobs being started

......
Aug 26 16:07:33 defiant anacron[17957]: Job `cron.weekly' started
Aug 26 16:07:33 defiant anacron[27690]: Updated timestamp for job `cron.weekly' to 2018-08-26
Aug 26 16:08:01 defiant anacron[17957]: Job `cron.weekly' terminated
....

and the log files are now rotating.

This may have been caused by an update as I found some rotated log files up to 16th July but I have not been able to find out more.

inxi output

System:    Host: defiant Kernel: 4.15.0-33-generic x86_64 bits: 64
           Desktop: Cinnamon 3.8.8  Distro: Linux Mint 19 Tara
Machine:   Device: laptop System: Notebook product: W230ST serial: N/A
           Mobo: Notebook model: W230ST serial: N/A
           BIOS: American Megatrends v: 4.6.5 date: 11/18/2013
Battery    BAT0: charge: 56.9 Wh 100.0% condition: 56.9/62.2 Wh (91%)
CPU:       Quad core Intel Core i7-4700MQ (-MT-MCP-) cache: 6144 KB
           clock speeds: max: 3400 MHz 1: 1995 MHz 2: 1996 MHz 3: 1995 MHz 4: 1995 MHz
           5: 1996 MHz 6: 1996 MHz 7: 1995 MHz 8: 1998 MHz
Graphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GK106M [GeForce GTX 765M]
           Display Server: x11 (X.Org 1.19.6 )
           drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@60.00hz
           OpenGL: renderer: Mesa DRI Intel Haswell Mobile version: 4.5 Mesa 18.0.5
Audio:     Card-1 Intel 8 Series/C220 Series High Def. Audio Controller
           driver: snd_hda_intel
           Card-2 Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller
           driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k4.15.0-33-generic
Network:   Card-1: Intel Centrino Advanced-N 6235 driver: iwlwifi
           IF: wlp3s0 state: up mac: c4:d9:87:0a:df:a2
           Card-2: Realtek RTL8111/8168/8411 PCIE Gigabit Ethernet Controller
           driver: r8169
           IF: enp4s0f1 state: down mac: 00:90:f5:f7:1d:5b
Drives:    HDD Total Size: 1250.3GB (47.5% used)
           ID-1: /dev/sda model: Samsung_SSD_860 size: 250.1GB
           ID-2: /dev/sdb model: ST1000LM014 size: 1000.2GB
Partition: ID-1: / size: 41G used: 27G (71%) fs: ext4 dev: /dev/sda2
           ID-2: /home size: 139G used: 30G (23%) fs: ext4 dev: /dev/sda4
           ID-3: swap-1 size: 16.78GB used: 0.00GB (0%) fs: swap dev: /dev/sdb3
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 65.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 299 Uptime: 5 days Memory: 5570.4/7896.9MB
           Client: Shell (bash) inxi: 2.3.56 

[gm10]

That directory exists on a clean installed, up-to-date LM19, so possibly something you changed/installed/etc. caused this for you. You may be able to find the cause if you go through your archived log files.

[pdcurtis]

When I looked at the date stamps on entries in /var/log for the system log I saw there are no entries between July 16 and August 29 although the machine was in use most days.

-rw-r-----  1 syslog            adm                 469 Aug 31 23:01 syslog
-rw-r-----  1 syslog            adm             7840516 Aug 31 23:01 syslog.1
-rw-r-----  1 syslog            adm             2938542 Aug 29 03:49 syslog.2.gz
-rw-r-----  1 syslog            adm               56441 Jul 16 04:38 syslog.3.gz
-rw-r-----  1 syslog            adm              173444 Jul 15 01:40 syslog.4.gz
-rw-r-----  1 syslog            adm                5878 Jul 14 02:17 syslog.5.gz
-rw-r-----  1 syslog            adm              421280 Jul 13 18:07 syslog.6.gz
-rw-r-----  1 syslog            adm               12590 Jul 12 05:07 syslog.7.gz

This led me back to 16 July which is the date I did a restore using Timeshift .

On inspection there is an exclusions in TimeShift for /var/spool/* so /var/spool/anacron would not be created.

So this is a problem in configuration of TimeShift in Mint 19 which will cause an error whenever a system is Restored using TimeShift

I have edited the Title to reflect the addition information.

[gm10]

That one I can confirm. This is something that was already fixed in timeshift back in June (https://github.com/teejee2008/timeshift/commit/eb2115a254ce4e9748f753c52dd7d2579e06c67e), but you're receiving timeshift via the Mint repo, which has an old version. They should really consider supporting their own repo better.

In the meantime, consider getting timeshift directly from its developer:

sudo add-apt-repository -y ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install timeshift

[pdcurtis]

@gm10 Thanks for the information. I am sure the Mint team will fix this very quickly as the consequences are quite serious for people who do a restore and the fix is simple. Timeshift is now fundamental to the Mint update philosophy which is much less conservative now TimeShift is used as a safety net.