6

I just restored my Raspberry Pi server from an rsync image. During the backup, I had excluded /var/cache/*, thinking that this would restore an empty directory. This worked, but when I rebooted, a process complained that it couldn't write to it in the following mail.

Subject: status report from ddclient@raspberrypi
...
WARNING:  updating <url>.dynu.com: nochg: No update required; unnecessary attempts to change to the current address are considered abusive
FATAL:    Cannot create file '/var/cache/ddclient/ddclient.cache'. (No such file or directory)

I checked the permissions of /var/log, which were consistent with my Arch desktop system.

$ ls -ld /var/cache/
drwxr-xr-x 3 root root 4096 Aug 15 13:23 /var/cache/

Do I have to do anything else? If the permissions are a-w, then how can non-root processes write in here?

Sparhawk
  • 19,941
  • Did you try to manually add the ddclient folder? on my machine the folder has 755 permissions and is owned by root. – chthonous Aug 16 '14 at 02:15
  • @chthonous I haven't yet, but I was considering doing so. My question was more generic. How do I prevent errors in general, and should I have excluded something else (e.g. /var/cache/*/*)? – Sparhawk Aug 16 '14 at 02:16
  • (N.B. I think /var/cache/*/* wouldn't really work conceptually, because there are nested directories within some of these first-level directories.) – Sparhawk Aug 16 '14 at 02:44

2 Answers2

7

/var/cache is not a free-for-all like /var/tmp. Each service that requires it has a subdirectory in /var/cache with appropriate permissions for it to store files.

On Debian and derived distributions, you can run dpkg -S /var/cache to find what packages have set up directories under /var/cache, and apt-get --reinstall install PACKAGE_NAME … to reinstall these packages and re-create the directories under /var/cache.

Some applications repopulate their cache on the fly. Others need to have the cache filled explicitly; this is often done by a cron job. A few need to be populated manually; for example, to use apt-file, you'll first need to run apt-file update as root.

There is one piece of /var/cache on Debian that cannot be reconstructed: /var/cache/debconf/config.dat. This file contains the answers that you gave during the installation of Debian packages. This is a long-standing bug in Debconf.

  • 1
    Thanks for the clarification (+1). I like the idea of running dpkg -S /var/cache. However, /var/cache/debconf was repopulated automatically for me on reboot. (This includes config.dat config.dat-old passwords.dat templates.dat templates.dat-old.) – Sparhawk Aug 17 '14 at 00:55
2

Fortunately I still had a copy of the corrupted filesystem, so I had some idea of what should go in /var/cache for my system.

cd /var/cache
sudo mkdir apache2 apt ddclient debconf dictionaries-common fontconfig ldconfig man modsecurity
sudo chmod a=,u=rwx ldconfig
sudo chmod g=rsx man
sudo chown man man
sudo chown www-data modsecurity
sudo mkdir apache2/mod_cache_disk 
sudo chown www-data:www-data apache2/mod_cache_disk

After apt-get update and a reboot, most of these directories were repopulated. However, there were several files missing in man, so I repopulated it with

sudo apt-get --reinstall install man

I also found that dictionaries-common and fontconfig were now empty, but I didn't worry about those, since I had no idea what they were doing on my headless server anyway! (Possibly ownCloud's dependency on Libreoffice.)

This information is probably specific to my system. In the future, I won't exclude /var/cache from backups.

Sparhawk
  • 19,941
  • 1
    I had a few directories in /var/cache symlinked to a RAID0, including man since I knew /var/cache/man doesn't have anything that can't be regenerated. But it was more complicated than I expected to do the re-generating: reinstalling man without doing the chown / chmod first didn't work. But with that, it worked fine. – Peter Cordes Nov 25 '16 at 12:14