You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
podman-systemd templated containers unable to work with templated volumes (and templated volumes separately have a failure and an inconvenience)
#25136
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.
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.
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.
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 infohost:
arch: amd64buildahVersion: 1.38.1cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- rdma
- misccgroupManager: systemdcgroupVersion: v2conmon:
package: conmon-2.1.12-3.fc41.x86_64path: /usr/bin/conmonversion: 'conmon version 2.1.12, commit: 'cpuUtilization:
idlePercent: 99.88systemPercent: 0.08userPercent: 0.05cpus: 8databaseBackend: sqlitedistribution:
distribution: fedoraversion: "41"eventLogger: journaldfreeLocks: 2044hostname: fedoraidMappings:
gidmap: nulluidmap: nullkernel: 6.12.10-200.fc41.x86_64linkmode: dynamiclogDriver: journaldmemFree: 13824925696memTotal: 16661622784networkBackend: netavarknetworkBackendInfo:
backend: netavarkdns:
package: aardvark-dns-1.13.1-1.fc41.x86_64path: /usr/libexec/podman/aardvark-dnsversion: aardvark-dns 1.13.1package: netavark-1.13.1-1.fc41.x86_64path: /usr/libexec/podman/netavarkversion: netavark 1.13.1ociRuntime:
name: crunpackage: crun-1.19.1-1.fc41.x86_64path: /usr/bin/crunversion: |- 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 +YAJLos: linuxpasta:
executable: /usr/bin/pastapackage: passt-0^20250121.g4f2c8e7-2.fc41.x86_64version: | 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: truepath: /run/podman/podman.sockrootlessNetworkCmd: pastasecurity:
apparmorEnabled: falsecapabilities: 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_CHROOTrootless: falseseccompEnabled: trueseccompProfilePath: /usr/share/containers/seccomp.jsonselinuxEnabled: trueserviceIsRemote: falseslirp4netns:
executable: ""package: ""version: ""swapFree: 8589930496swapTotal: 8589930496uptime: 22h 9m 53.00s (Approximately 0.92 days)variant: ""plugins:
authorization: nulllog:
- k8s-file
- none
- passthrough
- journaldnetwork:
- bridge
- macvlan
- ipvlanvolume:
- localregistries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.iostore:
configFile: /etc/containers/storage.confcontainerStore:
number: 1paused: 0running: 1stopped: 0graphDriverName: btrfsgraphOptions: {}graphRoot: /var/lib/containers/storagegraphRootAllocated: 724490518528graphRootUsed: 8092454912graphStatus:
Build Version: Btrfs v6.12Library Version: "104"imageCopyTmpDir: /var/tmpimageStore:
number: 43runRoot: /run/containers/storagetransientStore: falsevolumePath: /var/lib/containers/storage/volumesversion:
APIVersion: 5.3.2Built: 1737504000BuiltTime: Wed Jan 22 00:00:00 2025GitCommit: ""GoVersion: go1.23.4Os: linuxOsArch: linux/amd64Version: 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
The text was updated successfully, but these errors were encountered:
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.
Issue Description
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.
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.
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:
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 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
The text was updated successfully, but these errors were encountered: