Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman-systemd templated containers unable to work with templated volumes (and templated volumes separately have a failure and an inconvenience) #25136

Open
Domini opened this issue Jan 27, 2025 · 1 comment
Labels
kind/bug Categorizes issue or PR as related to a bug. quadlet

Comments

@Domini
Copy link

Domini commented Jan 27, 2025

Issue Description

  1. Volume failure
    When you define a templated volume and an instance, e.g. [email protected], ln -s [email protected] [email protected], generator creates a [email protected] with an ExecStart=/usr/bin/podman volume create --ignore systemd-test@abc. It fails as volume names cannot contain special characters (Error: running volume create option: names must match [a-zA-Z0-9][a-zA-Z0-9_.-]*: invalid argument). Note, here instance name is properly hardcoded as abc.

  2. Volume inconvenience
    It is somewhat easy to fix - you add [Volume] VolumeName=test-%i, ExecStart now looks right ExecStart=/usr/bin/podman volume create --ignore test-%i.

But remember, the generated service is called [email protected], not [email protected]. When systemd starts this service, instance name is abc-volume, not abc, and volume created is test-abc-volume, not test-abc.

  1. Interoperability failure

3.1.
Now you define templated service and an instance, e.g. [email protected], ln -s [email protected] [email protected]. You include the templated volume with one of the two ways.

Mount=type=volume,source=[email protected],target=/tmp
Volume=[email protected]:/tmp

Generator generates a somewhat proper service, inheriting VolumeName from [email protected], and creates the following ExecStart, Requires and After

--mount type=volume,source=test-%i,target=/tmp
Requires=[email protected]
After=[email protected]

But, remember, service instance name is abc, but when it calls [email protected] its instance name is abc-volume. systemctl start [email protected] creates volume test-abc-volume explicitly by calling [email protected], then podman runs a container referencing volume test-abc (not test-abc-volume), and a volume test-abc is implicitly created and used by the container. Volume test-abc-volume is left dangling.

3.2. If you change templated volume inclusion to

Mount=type=volume,source=test@%i.volume,target=/tmp
Volume=test@%i.volume:/tmp

service unit would fail to generate.

3.3. If you change templated volume inclusion to (the way I think it was intended)

Mount=type=volume,source=[email protected],target=/tmp
Volume=[email protected]:/tmp

generator creates the following ExecStart, Requires and After

--mount type=volume,source=test-%i,target=/tmp
Requires=[email protected]
After=[email protected]

It's the worst of both worlds:

  • wrong volume service is being explicitly called, it creates a dangling test--volume as instance name for the volume call is -volume
  • podman run implicitly creates test-abc and uses it.

Steps to reproduce the issue

Please, see description.

Describe the results you received

Please, see description.

Describe the results you expected

Without VolumeName, volume name should be something like systemd-test-abc.
With VolumeName, -volume suffix should be stripped from the instance name, and the volume created should be test-abc.
Container service should reference [email protected] in all cases.

Preferably this should be fixed by changing the generated volume services name pattern for [email protected] to [email protected] instead of [email protected], so that instance name is the same in the generated container and volume.

This could be fixed by ugly hacks with ExecStart using sh and modifying %i value in runtime (see my comment below where this is done for a temporary workaround), however, that would be a pity.

podman info output

# podman info
host:
  arch: amd64
  buildahVersion: 1.38.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.12-3.fc41.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: '
  cpuUtilization:
    idlePercent: 99.88
    systemPercent: 0.08
    userPercent: 0.05
  cpus: 8
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    version: "41"
  eventLogger: journald
  freeLocks: 2044
  hostname: fedora
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.12.10-200.fc41.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 13824925696
  memTotal: 16661622784
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.13.1-1.fc41.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.13.1
    package: netavark-1.13.1-1.fc41.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.13.1
  ociRuntime:
    name: crun
    package: crun-1.19.1-1.fc41.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.19.1
      commit: 3e32a70c93f5aa5fea69b50256cca7fd4aa23c80
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20250121.g4f2c8e7-2.fc41.x86_64
    version: |
      pasta 0^20250121.g4f2c8e7-2.fc41.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 8589930496
  swapTotal: 8589930496
  uptime: 22h 9m 53.00s (Approximately 0.92 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: btrfs
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 724490518528
  graphRootUsed: 8092454912
  graphStatus:
    Build Version: Btrfs v6.12
    Library Version: "104"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 43
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.3.2
  Built: 1737504000
  BuiltTime: Wed Jan 22 00:00:00 2025
  GitCommit: ""
  GoVersion: go1.23.4
  Os: linux
  OsArch: linux/amd64
  Version: 5.3.2

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

No

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

@Domini Domini added the kind/bug Categorizes issue or PR as related to a bug. label Jan 27, 2025
@Luap99 Luap99 added the quadlet label Jan 27, 2025
@Domini
Copy link
Author

Domini commented Jan 28, 2025

Before this is fixed, I can suggest the following workaround for template volumes themselves.

If your template volume has VolumeName=X-%i-Y,

[Service]
ExecStartPost=/usr/bin/sh -c '/usr/bin/podman volume exists X-$(basename "%i" "-volume")-volume-Y && /usr/bin/podman volume rm X-$(basename "%i" "-volume")-volume-Y'
ExecStartPost=/usr/bin/sh -c '/usr/bin/podman volume create --ignore X-$(basename "%i" "-volume")-Y'

Notes:

  • I have not tested this with very special instance names, so I'm not sure how they would be escaped - be careful
  • I intentionally did X-$(basename "%i" "-volume")-volume-Y instead of just X-%i-Y, so that this workaround does no harm when this is fixed (when %i no longer ends with -volume) - you can remove it when you notice after an update
  • if you have instance names organically ending with -volume (i.e. generated service is [email protected]), this will break ungracefully when this is fixed - be careful
  • you can use this trick with Exec...=/usr/bin/sh -c '...$(basename "%i" "-volume")...' to get the organic instance name without -volume suffix for other Exec overrides until this is fixed

No workaround for referencing the template volume from the template container, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. quadlet
Projects
None yet
Development

No branches or pull requests

2 participants