podman: database libpod temporary files directory (tmpdir) "/tmp/run-1000/libpod/tmp" does not match our libpod temporary files directory (tmpdir) "/run/user/1000/libpod/tmp": database configuration mismatch

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I’ve first run rootless podman via su - user session from root. It was giving me warning messages

WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs    
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs    

but it worked.

I then thought, OK, I will log in to the machine properly. I’ve logged in via ssh. But then podman fails with

Error: could not get runtime: database libpod temporary files directory (tmpdir) "/tmp/run-1000/libpod/tmp" does not match our libpod temporary files directory (tmpdir) "/run/user/1000/libpod/tmp": database configuration mismatch

Steps to reproduce the issue:

  1. Create fresh user via useradd user
  2. su - user to the user and run podman images
  3. ssh user@machine and run podman images

Describe the results you received:

  1. Gives me
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs    
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs    
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE
  1. gives me
Error: could not get runtime: database libpod temporary files directory (tmpdir) "/tmp/run-1000/libpod/tmp" does not match our libpod temporary files directory (tmpdir) "/run/user/1000/libpod/tmp": database configuration mismatch

Describe the results you expected:

No error, I shouldn’t be bothered by podman/libpod picking different location in each case. Also, similar to https://github.com/containers/libpod/issues/5932, the error message gives no indication about how to fix this, where that database libpod temporary files directory is configured.

Additional information you deem important (e.g. issue happens only occasionally):

Deterministic. Can be re-reproduced by removing ~/.local and repeating steps 2 and 3.

Output of podman version:

Error: could not get runtime: database libpod temporary files directory (tmpdir) "/tmp/run-1000/libpod/tmp" does not match our libpod temporary files directory (tmpdir) "/run/user/1000/libpod/tmp": database configuration mismatch

Output of podman info --debug:

Error: could not get runtime: database libpod temporary files directory (tmpdir) "/tmp/run-1000/libpod/tmp" does not match our libpod temporary files directory (tmpdir) "/run/user/1000/libpod/tmp": database configuration mismatch

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.9.0-1.fc31.aarch64

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 25 (22 by maintainers)

Commits related to this issue

Most upvoted comments

Two possible workarounds:

  1. Executing loginctl enable-linger $(id -u admin) before doing sudo -i -u admin ...
  2. Or once you broke it (not using 1.) and log in as admin and actually see this issue, doing rm ~/.local/share/containers/storage/libpod/* solves the problem.