This still seems to exist in the current release of Xenial; setting the sandbox user to root bypasses the problem, leaving it at the default means any cron job that calls 'apt-get update' breaks, because gpgv exits with error 2 (unexpected error), which leads to a failure of the 'apt-key' action being executed.
The difference, as far as I can tell thus far, seems to be in that the '_apt' user cannot read the 'pubring.gpg' file that is being created in a temporary directory, which means that gpgv cannot access it when it runs;
This problem does not occur when root is the sandbox user, set via 'APT::Sandbox::User "root";' in '/etc/apt/apt.conf'. It's the only setting present. Disable that setting and the problem returns, while running the same thing interactively works without any issues.
I'm a bit stumped, at this point, pausing my investigation for now, but logging it here in case someone else runs into this.
This still seems to exist in the current release of Xenial; setting the sandbox user to root bypasses the problem, leaving it at the default means any cron job that calls 'apt-get update' breaks, because gpgv exits with error 2 (unexpected error), which leads to a failure of the 'apt-key' action being executed.
The difference, as far as I can tell thus far, seems to be in that the '_apt' user cannot read the 'pubring.gpg' file that is being created in a temporary directory, which means that gpgv cannot access it when it runs;
== etc/apt/ trusted. gpg", {st_mode= S_IFREG| 0644, st_size=12255, ...}) = 0 trusted. gpg", R_OK) = 0 tmp/tmp. OcaWlGuT32/ pubring. gpg", O_WRONLY| O_CREAT| O_APPEND, 0666) = -1 EACCES (Permission denied) OcaWlGuT3" ..., 64) = 64
[pid 10149] stat("/
[pid 10149] faccessat(AT_FDCWD, "/etc/apt/
[pid 10149] open("/
[pid 10149] write(2, "/usr/bin/apt-key: 309: /usr/bin/"..., 41) = 41
[pid 10149] write(2, "cannot create /tmp/tmp.
==
This problem does not occur when root is the sandbox user, set via 'APT::Sandbox::User "root";' in '/etc/apt/ apt.conf' . It's the only setting present. Disable that setting and the problem returns, while running the same thing interactively works without any issues.
I'm a bit stumped, at this point, pausing my investigation for now, but logging it here in case someone else runs into this.
The warning we're seeing looks as follows;
== /apt-cache. domain. example/ cache/us- east-1. ec2.archive. ubuntu. com/ubuntu xenial InRelease: Unknown error executing apt-key
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https:/
==
Using the HTTPS transport to a local cache, fresh Xenial install based on the official AMI, on AWS.