podman generate systemd --new doesn't support containers created with -h hostname

[Nemykal]

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

/kind bug

Description

Using podman generate systemd --new fails if container has a dash in its name container was created with -h hostname option

EDIT: I was mistaken when trying to narrow down what the problem was originally; it's not the dash in the container name, it's just the presence of the -h hostname option that podman-generate-systemd doesn't like

Steps to reproduce the issue:

1. Create a container and specify a hostname with -h hostname

# podman create --name victoria-metrics -v /srv/victoria-metrics-data:/victoria-metrics-data -h victoria-metrics -p 8428:8428 \
--label "io.containers.autoupdate=registry" victoriametrics/victoria-metrics:latest

2. Try to generate a systemd service for the container:

# podman generate systemd --new --name victoria-metrics
Error: parsing remaining command-line arguments: pflag: help requested

Describe the results you received:

Error: parsing remaining command-line arguments: pflag: help requested

Describe the results you expected:

# container-victoriametrics.service
# autogenerated by Podman 4.1.1
...

It works fine if I use a different name for the container (i.e. victoriametrics with no dash / hyphen)

It works if I don't specify the -h hostname while creating/running the container

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

Another minimal reproducible test case:

# podman create --name test -h test alpine:latest
# podman generate systemd --new --name test
Error: parsing remaining command-line arguments: pflag: help requested

Output of podman version:

Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.3
Git Commit:   f73d8f8875c2be7cd2049094c29aff90b1150241
Built:        Fri Jun 24 17:33:56 2022
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.26.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon is owned by conmon 1:2.1.3-1
    path: /usr/bin/conmon
    version: 'conmon version 2.1.3, commit: ab52a597278b20173440140cd810dc9fa8785c93'
  cpuUtilization:
    idlePercent: 99.82
    systemPercent: 0.1
    userPercent: 0.09
  cpus: 4
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  hostname: ambrosia
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.18.14-arch1-1
  linkmode: dynamic
  logDriver: journald
  memFree: 28791193600
  memTotal: 33484857344
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: /usr/bin/crun is owned by crun 1.5-1
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    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,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: /usr/bin/slirp4netns is owned by slirp4netns 1.2.0-1
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 1073737728
  swapTotal: 1073737728
  uptime: 23h 10m 38.55s (Approximately 0.96 days)
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /srv/containers/storage
  graphRootAllocated: 682689896448
  graphRootUsed: 11583840256
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 5
  runRoot: /run/containers/storage
  volumePath: /srv/containers/storage/volumes
version:
  APIVersion: 4.1.1
  Built: 1656056036
  BuiltTime: Fri Jun 24 17:33:56 2022
  GitCommit: f73d8f8875c2be7cd2049094c29aff90b1150241
  GoVersion: go1.18.3
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.1

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

podman 4.1.1-2

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

Yes

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

Physical

[Luap99]

I cannot reproduce. The problem should not be the name.
The error sounds like you have -h or --help in your command somewhere.

[Nemykal]

Sorry, I was mistaken - it's not the dash in the container name, it's actually just the presence of the -h hostname option on the podman-create command

[rhatdan]

Change it to --hostname and it should work, although that is suppose to work.