error in podman generate systemd

arajczy commented 3 years ago

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

bug

Description

Error in the value of ExecStart of podman generate systemd.

podman run args --rm and --restart=always mutually exclusive. It prevents starting container as a service as it gives the below error:

podman[…]: Error: the --rm option conflicts with --restart, when the restartPolicy is not "" and "no"

Steps to reproduce the issue:

podman run -d \ --restart=always \ --tz=Europe/Budapest \ -p 27017:27017 \ -v mongoconfig:/data/configdb \ -v mongodata:/data/db \ -v mongodump:/dump \ --name=mongo \ docker.io/library/mongo:4 --auth
podman generate systemd --files --new --name mongo
podman rm -f mongo
systemctl enable --now container-mongo.service

Describe the results you received:

podman[6745]: Error: the --rm option conflicts with --restart, when the restartPolicy is not "" and "no"

Describe the results you expected:

enable and start container as a service

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

I have removed the arg --rm from the ExecStart in the service file and I could start the service successfully.

Output of podman version:

Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.6
Built:        Mon Aug 30 22:45:47 2021
OS/Arch:      linux/arm64

Output of podman info --debug:

host:
  arch: arm64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.29-2.fc34.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: '
  cpus: 4
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: rpi5
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 5.13.13-200.fc34.aarch64
  linkmode: dynamic
  memFree: 6747824128
  memTotal: 8149852160
  ociRuntime:
    name: crun
    package: crun-1.0-1.fc34.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.0
      commit: 139dc6971e2f1d931af520188763e984d6cdfbf8
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1001/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,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc34.aarch64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 8149528576
  swapTotal: 8149528576
  uptime: 6m 23.11s
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/pod/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/pod/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/user/1001/containers
  volumePath: /home/pod/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 1630356347
  BuiltTime: Mon Aug 30 22:45:47 2021
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/arm64
  Version: 3.3.1

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

podman-3.3.1-1.fc34.aarch64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

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

mheon commented 3 years ago

@vrothberg PTAL, we'll probably need to catch this in generate systemd.

Luap99 commented 3 years ago

I think we can remap the container restart policy to a systemd restart policy and remove the --restart from the podman run command.

vrothberg commented 3 years ago

I think we can remap the container restart policy to a systemd restart policy and remove the --restart from the podman run command.

I concur :+1:

rugk commented 3 years ago

Just stumbled into this and wonder why the error even happens? Should not it be valid to use --rm and --restart-policy together?

In https://github.com/containers/podman/issues/7906 this was once raised and apparently allowed/fixed in https://github.com/containers/podman/pull/8263?

Nevertheless, I agree that mapping the podman restart-policy to a systemd restart policy is a good thing to do.

And AFAIK it also used to work before 3.3.0 with both arguments combined or so, but I'm not sure. I.e. with --restart unless-stopped and --rm.

$ podman version
Version:      3.3.0
API Version:  3.3.0
Go Version:   go1.16.6
Built:        Fri Aug 20 21:36:14 2021
OS/Arch:      linux/amd64

Also you need to make sure your fix does not break the healthcheck feature – that podman still restarts on a failed healthcheck.

vrothberg commented 3 years ago

--rm is only allowed with on-failure as a restart policy.

containers / podman

error in podman generate systemd #11438