'podman system reset' shouldn't nuke unrelated things in $XDG_RUNTIME_DIR

[debarshiray]

/kind bug

Description

I tried resetting the rootless Podman storage using podman system reset a few times over the last week. On at least one occasion it tried to remove almost everything inside $XDG_RUNTIME_DIR, and not just the container bits like $XDG_RUNTIME_DIR/overlay-* or $XDG_RUNTIME_DIR/containers. Among the things that disappeared were the session D-Bus, Pipewire and Wayland sockets. The attempt to remove $XDG_RUNTIME_DIR/doc which is a FUSE mount point for Flatpak even led to:

Error: unlinkat /run/user/1000/doc/by-app/org.gnome.Documents: function not implemented

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

This didn't happen on every podman system reset run, though. Other times it seemed to restrict itself to the relevant container-specific directories.

Output of podman version:

Version:            1.7.0-rc2
RemoteAPI Version:  1
Go Version:         go1.13.5
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.5
  podman version: 1.7.0-rc2
host:
  BuildahVersion: 1.12.0
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.2-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.2, commit: 186a550ba0866ce799d74006dab97969a2107979'
  Distribution:
    distribution: fedora
    version: "31"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 1125044224
  MemTotal: 8107823104
  OCIRuntime:
    name: crun
    package: crun-0.10.6-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 4133482496
  SwapTotal: 4133482496
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: kolache
  kernel: 5.4.7-200.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 50m 25.39s
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /home/rishi/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.2-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.2
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/rishi/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 1
  RunRoot: /run/user/1000/containers
  VolumePath: /home/rishi/.local/share/containers/storage/volumes

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

podman-1.7.0-0.4.rc2.fc31.x86_64

[rhatdan]

Strange. I thought we had fixed it, with a PR to containers/storage.

[apollo13]

In my case it also just removed everything from /run/user/1000 -- it complained that it couldn't remove the gvfs folder (that's how I noted it in the first place). Luckily I didn't have anything mounted and mapped to there :)

rpm -q podman
podman-1.7.0-2.fc31.x86_64

[mheon]

I think we need to just delete the c/storage directories, instead of the entire temporary directory - we still have a lot of old installs with /run/user/$UID as tmpdir, not a subdirectory

[vrothberg]

Friendly ping. @rhatdan, did you have the chance to look into this?

[rhatdan]

@QiWang19 PTAL

[rhatdan]

@QiWang19 Reminder.

[QiWang19]

I can't replicate this issue. For me podman system reset only removes /run/user/1000/containers

Do we need to make these changes, to not remove /run/user/$UID/containers in system reset?

I think we need to just delete the c/storage directories, instead of the entire temporary directory - we still have a lot of old installs with /run/user/$UID as tmpdir, not a subdirectory

[mheon]

The problem is if our temporary directory is set to /run/user/1000 - which it was, on some older systems. In that case, we remove all the contents of the directory - including things that are definitely not Podman.

[rhatdan]

@mheon So what do we do? Is this an upgrade issue? New versions of podman all use the containers subdir. Did we record something in the database that causes us the issues?

[mheon]

Yeah, upgrade issue - older installations use /run/user/$UID/ with no subdirectory for one of the tmpdirs (I forget if it's c/storage or Podman... Might actually be c/storage?)

[rhatdan]

Yes it is in container/storage. But would a reboot fix the /run directive or only a full clean?

[mheon]

Only a full clean - it's potentially in both the database and libpod.conf

[rhatdan]

Ok lets check to see if the director == $XDG_RUNTIME_DIR, and not remove it in that case. If it is containers then it should be removed.