[Quadlet] DefaultInstance is ignored when installing generated unit

[mfschumann]

Issue Description

I've defined a template unit pcloud@.container that I want to run multiple instances of. The unit has a [Install] section because I want a default instance based on the template to be enabled automatically. In order to specify a default instance, you can set DefaultInstance= in ordinary systemd units. This instance is effective when enabling the template unit without explicitly specifying an instance.

Template units generated and automatically enabled by quadlet seem to ignore DefaultInstance=: The links created in e.g. /run/systemd/generator/default.target.wants are named like the plain template units (pcloud@.service), i.e. without setting the instance to the given default instance. Instead, I would wish that quadlet behaves consistently to systemctl enable in that it honors DefaultInstance= for template units, i.e. create a symlink named pcloud@martin.service if DefaultInstance=martin in the template unit.

Steps to reproduce the issue

Steps to reproduce the issue

1. Create a template unit foo@.container including this section:

[Install]
WantedBy=default.target
DefaultInstance=example

2. systemctl daemon-reload

Describe the results you received

/run/systemd/generator/default.target.wants/foo@.service is created.

Describe the results you expected

/run/systemd/generator/default.target.wants/foo@example.service is created, being a symlink to ../foo@.service.

podman info output

host:
  arch: amd64
  buildahVersion: 1.29.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.6-3.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: '
  cpuUtilization:
    idlePercent: 97.65
    systemPercent: 0.65
    userPercent: 1.7
  cpus: 4
  distribution:
    distribution: fedora
    variant: iot
    version: "37"
  eventLogger: journald
  hostname: srv4.mfs.name
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.1.13-200.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 701988864
  memTotal: 4105961472
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.8-1.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8
      commit: 0356bf4aff9a133d655dc13b1d9ac9424706cac4
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  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
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 4104908800
  swapTotal: 4105170944
  uptime: 1h 14m 7.00s (Approximately 0.04 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.mfs.name
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 21
    paused: 0
    running: 19
    stopped: 2
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 82945986560
  graphRootUsed: 61522329600
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 32
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.4.1
  Built: 1676629579
  BuiltTime: Fri Feb 17 11:26:19 2023
  GitCommit: ""
  GoVersion: go1.19.5
  Os: linux
  OsArch: linux/amd64

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

No

Additional environment details

No response

Additional information

No response

[vrothberg]

Thanks for reaching out, @mfschumann!

I am not sure templates are supported by Quadlet. @alexlarsson PTAL

[ygalblum]

@vrothberg you are correct. Currently, Quadlet does not support unit templates.

[mfschumann]

How about adding a note in the man page about the missing support or issuing a warning when trying to run quadlet for template units then? Without that, people not knowing about the missing support (like me) may assume that everything worked as expected, but end up with an unexpected result (i.e. a unit like foo@multi-user appearing seemingly out of nowhere).

Btw, the documentation could make it clearer that adding an [Install] section in the .container file does not prepare the unit for being enabled (as for regular units), but directly enables it. That was quite unexpected for me, too.

[ygalblum]

Btw, the documentation could make it clearer that adding an [Install] section in the .container file does not prepare the unit for being enabled (as for regular units), but directly enables it. That was quite unexpected for me, too.

Please see: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#enabling-unit-files. Let me know if you think a rephrase is needed.

[ygalblum]

How about adding a note in the man page about the missing support or issuing a warning when trying to run quadlet for template units then? Without that, people not knowing about the missing support (like me) may assume that everything worked as expected, but end up with an unexpected result (i.e. a unit like foo@multi-user appearing seemingly out of nowhere).

I think we should decide if we would like to support templates. If not, then I think Quadlet should fail the processing of the file, not just issue a warning.

[vrothberg]

I think we should decide if we would like to support templates. If not, then I think Quadlet should fail the processing of the file, not just issue a warning.

Interesting question. Which attribute would be used to instantiate a template? I have a hard time imaging atm.

[ygalblum]

Which attribute would be used to instantiate a template?

@mfschumann can you share some more information about what you were trying to achieve?

[mfschumann]

Btw, the documentation could make it clearer that adding an [Install] section in the .container file does not prepare the unit for being enabled (as for regular units), but directly enables it. That was quite unexpected for me, too.

Please see: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#enabling-unit-files. Let me know if you think a rephrase is needed.

This looks fine to me. I (or my podman 4.4.0 installation) must have missed the section when I had looked through the man page.

[mfschumann]

Which attribute would be used to instantiate a template?

@mfschumann can you share some more information about what you were trying to achieve?

I am using a cloud storage provider with multiple accounts and I want to back up the data stored there.
Before using quadlet, I created a template unit for running the containerized cloud storage daemon and backup software using podman generate systemd. I could then use systemd start and systemd enable to instantiate units for the different accounts. I found that workflow quite comfortable.

I understand that because of systemd's design decision about enabling generated units this workflow is not achievable with quadlet. So when opening this issue I thought it would be a good idea to support the DefaultInstance= parameter, so that one instance is installed when running systemctl daemon-reload. Admittedly that is only a partial solution because it would create only one instance per template unit, which is probably not the most relevant use case (Why create a template unit if you only need one instance?). For enabling more instances you still have to resort to manually creating symlinks between /etc/systemd/system and /run/systemd/generator which is discouraged.

I think it would be more useful to introduce a new parameter in the [Install] section called Instances= which accepts a list of instances. When running systemctl daemon-reload quadlet will parse the parameter and instantiate the template unit by creating symlinks within /run/systemd/generator. That would avoid the discouraged dependency between static and generated config and provide a comfortable way to install instances of template units that is in line with the behavior of quadlet for ordinary, non-template units.

[rhatdan]

Would that be an anti-pattern by systemd?

@vrothberg @ygalblum WDYT?

[ygalblum]

@rhatdan not sure what you mean by anti-pattern. But, I wouldn't want to add Quadlet parameters to any generic Systemd section.
Please see the discussion we had here: #17567 (comment). Maybe a podman quadlet enable foo@ygal.container command will work here?
@alexlarsson WDYT?

[mfschumann]

@ygalblum Would podman quadlet enable foo@ygal.container create symlinks in /etc/systemd/system or in /run/systemd/generator?

[ygalblum]

I think it will follow what Quadlet does today. That is along side the location of the generated service file: /run/systemd/generator for system services and $XDG_RUNTIME_DIR/generator for user services.

So, first it would have to receive a -user parameter to differentiate between them. In addition, since these paths are not guaranteed (according to the man page), it would have to be able to get an optional parameter for the location of the service files.