FS#63311 - error: could not access cache directory /var/cache/pacman/pkg/ breaks Dockerfiles

Attached to Project: Arch Linux
Opened by Wagner (chriswayg) - Monday, 29 July 2019, 11:47 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 11 August 2019, 02:58 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Cleaning the cache with `pacman -Scc` in a Dockerfile used to work without errors, but now it throws an unnecessary error, with an exit code of 1.

* Pacman v5.1.3 - libalpm v11.0.3

Steps to reproduce:

```
[root@5 /]# yes | pacman -Scc
Cache directory: /var/cache/pacman/pkg/
:: Do you want to remove ALL files from cache? [y/N] y
removing all files from cache...

error: could not access cache directory /var/cache/pacman/pkg/

Database directory: /var/lib/pacman/
:: Do you want to remove unused repositories? [Y/n] y
removing unused sync repositories...

[root@5 /]# echo $?
1
```
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Sunday, 11 August 2019, 02:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  Problem with hook shipped by docker image, fixed in https://github.com/archlinux/archlinux-d ocker/pull/15
Comment by Eli Schwartz (eschwartz) - Monday, 29 July 2019, 12:21 GMT
And why, precisely, is it saying "error: could not access cache directory /var/cache/pacman/pkg/" -- that error should not be happening since the directory is provided by the pacman package. If the directory truly does not exist, then pacman is correctly behaving as expected, because that's a pretty big error and it is erroring as it should.

So I really could not possibly care less what Dockerfile is broken -- if a Dockerfile fails because it aborts due to errors, and the command it is running has an error, then *of course* the Dockerfile will be broken. But I would be interested to know why your system is broken in a way that other people's systems aren't.
Comment by Wagner (chriswayg) - Tuesday, 30 July 2019, 07:31 GMT
@eschwartz I agree with one point you make: "that error should not be happening"! Now please explain to me, why this error regularly and reproducibly happens when clearing the package cache? Maybe I should resubmit the bug report with a changed title:

*Cleaning the package cache with `pacman -Scc` repeatedly throws an error during normal operations.*

Therefore pacman is NOT correctly behaving as expected:

Expected bahaviour:
https://wiki.archlinux.org/index.php/Pacman#Cleaning_the_package_cache
# pacman -Scc

If that commands deletes the directory /var/cache/pacman/pkg/ (while presumably it should not), it needs to be fixed. If that command falsely identifies /var/cache/pacman/pkg/ as missing or inaccessible, then it should also be fixed. Just try to reproduce it. For about a year this was working correctly, but now it throws an error, even though nothing else has changed.

The command itself is apparently causing the error by the way it operates. No other command has been acting on that directory. The installation is based on the official archlinux base image on Docker Hub.

The error occurs right after installing two packages:

DOCKERFILE:
FROM archlinux/base:latest

# Update, install sudo and systemd, cleanup and remove unneeded unit files.
RUN pacman -S -y \
&& pacman -S --noconfirm \
sudo \
systemd \
&& yes | pacman -Scc || true

Other people (example and link below) do have the same problem and if they use the `pacman -Scc` command, they set it to ignore the error, which I have also done as a workaround. Maybe they did not bother to report it here. https://gitlab.feildel.fr/bfeildel/aurtomatic/-/jobs/936

HEAD is now at d1696a7 Fix missing directory error
Step 6/7 : RUN yes | pacman -Scc || true
---> Running in 9f5b4925ba55
:: Do you want to remove ALL files from cache? [y/N] y

Cache directory: /var/cache/pacman/pkg/
removing all files from cache...
Database directory: /var/lib/pacman/
error: could not access cache directory /var/cache/pacman/pkg/
:: Do you want to remove unused repositories? [Y/n] y
removing unused sync repositories...

And https://gitlab.feildel.fr/bfeildel/aurtomatic-docker/blob/master/Dockerfile

FROM archlinux/base:latest
MAINTAINER Baudouin Feildel <baudouin@feildel.fr>

# Make sure pacman keyring is initialized
RUN pacman-key --init

# Synchronize database and upgrade packages
RUN pacman -Syu --noconfirm

# Install common build dependencies and tools that will be needed by build script
RUN pacman -S --noconfirm base-devel grep tar sudo openssh git go php cunit nodejs npm python python2 cmake jq clang llvm

# Clean uneeded pacman cache (can fail it is not a mandatory step)
RUN yes | pacman -Scc || true

CMD ["/usr/bin/bash"]

Comment by Eli Schwartz (eschwartz) - Tuesday, 30 July 2019, 14:03 GMT
> If that commands deletes the directory /var/cache/pacman/pkg/ (while presumably it should not), it needs to be fixed. If that command falsely identifies /var/cache/pacman/pkg/ as missing or inaccessible, then it should also be fixed. Just try to reproduce it. For about a year this was working correctly, but now it throws an error, even though nothing else has changed.

That command does not delete the directory. That command does not falsely identify the directory as missing or inaccessible.

> The command itself is apparently causing the error by the way it operates. No other command has been acting on that directory. The installation is based on the official archlinux base image on Docker Hub.

That command apparently works everywhere except on Docker. (I assure you it works flawlessly on my laptop, which it should since I have lots of packages cached there that had better not disappear on me when I don't want them to.) I propose you figure out what is so special about Docker.

Have you tried using ls inside the container to figure out whether the directory exists before and after running pacman -S? Have you tried running type -a pacman, to find out whether you're using a dangerous wrapper script over pacman? You cannot be using a pacman hook that runs paccache, because paccache is well written and doesn't break pacman.
Comment by Bryan L. Gay (linuxninja) - Saturday, 10 August 2019, 04:49 GMT
I was able to replicate this issue in docker.
Pulled docker image ID 5e2b896c9d63 (currently tagged 'latest')
docker run -it --rm archlinux/base
# ls -al /var/cache/pacman/pkg/
Output shows directory exists and is empty.
# pacman-key --init
Succeeds.
# ls -al /var/cache/pacman/pkg/
Still shows directory exists and is empty.
# pacman -Syu --noconfirm
:: Synchronizing package databases...
core 132.2 KiB 1717K/s 00:00 [######################################################################################################] 100%
extra 1630.1 KiB 7.24M/s 00:00 [######################################################################################################] 100%
community 4.9 MiB 13.9M/s 00:00 [######################################################################################################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (3) archlinux-keyring-20190805-1 keyutils-1.6.1-1 shadow-4.7-2
...output key list not shown for sanity reasons...
==> Updating trust database...
gpg: next trustdb check due at 2019-10-26
(2/3) upgrading keyutils [######################################################################################################] 100%
(3/3) upgrading shadow [######################################################################################################] 100%
:: Running post-transaction hooks...
(1/3) Cleaning up package cache...
(2/3) Reloading system manager configuration...
Skipped: Current root is not booted.
(3/3) Arming ConditionNeedsUpdate...
# ls -al /var/cache/pacman/pkg/
ls: cannot access '/var/cache/pacman/pkg/': No such file or directory

Installing any one of those three packages causes the issue, so I then tested the hooks. The HookDir in /etc/pacman.conf is commented out, so the default HookDir is /usr/share/libalpm/hooks/
/usr/share/libalpm/hooks/package-cleanup.hook contains:
[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Cleaning up package cache...
Depends = coreutils
When = PostTransaction
Exec = /usr/bin/rm -rf /var/cache/pacman/pkg

I verified manually that running this command does indeed remove the pkg directory. This is a bug in the Archlinux DockerHub image.

I then verified that Arch Linux proper does NOT contain this hook file. This is not a 'Docker' problem, this is a problem with the DockerHub image containing a hook with a 'rm' command that deletes the /var/cache/pacman/pkg directory after the installation of ANY package. Either the Exec needs to re-create the directory after deletion, or not delete the directory but only the files within it.
Comment by Bryan L. Gay (linuxninja) - Saturday, 10 August 2019, 06:12 GMT
I pulled the repo: git@github.com:archlinux/archlinux-docker.git

The file package-cleanup.hook is indeed added by the docker image build process (commit 601fcd25268889138b7228ce932416d59d11c7eb April 8, 2017)

It looks like this has been broken for quite some time. A single run of pacman -S will work fine, and the hook will clean (and delete) the /var/cache/pacman/pkg/ directory.
Subsequent runs of pacman -S will re-create the directory with:

warning: no /var/cache/pacman/pkg/ cache exists, creating...

Which is again deleted by the hook.

Remove the pacman -Scc from your Dockerfile, as it isn't needed at all, and the way the hook is written, it is actually broken.
I am submitting a PR to fix it. Once fixed, if my PR is accepted, you will still not need to run pacman -Scc . Just let the hook do its job for you.
Comment by Bryan L. Gay (linuxninja) - Saturday, 10 August 2019, 06:21 GMT Comment by Bryan L. Gay (linuxninja) - Saturday, 10 August 2019, 20:36 GMT
The fix has been merged in the repo. Waiting for the update of the DockerHub image.
Comment by Eli Schwartz (eschwartz) - Sunday, 11 August 2019, 02:57 GMT
Thanks for your great detective work!

Loading...