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 run always shows Error: requires at least 1 arg(s), only received 0 #20260

Closed
cold-distance opened this issue Oct 4, 2023 · 1 comment
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@cold-distance
Copy link

Issue Description

Hi, every time I try to run a container in Podman I get the next error message: Error: requires at least 1 arg(s), only received 0

I tried a container from Red Hat and another that I created my self based on another and I have the same error. I'm following the instructions from a book, so I think that the command is correct. I tried several combinations, removing some arguments and I always have the same error.

I'm using an updated version/snapshot of openSUSE MicroOS. I can run the container from Podman Desktop, but not from the command line.

Podman version:

Client:       Podman Engine
Version:      4.7.0
API Version:  4.7.0
Go Version:   go1.21.1
Built:        Fri Sep 29 02:00:00 2023
OS/Arch:      linux/amd64

rpm -q podman:
podman-4.7.0-1.1.x86_64

Steps to reproduce the issue

Steps to reproduce the issue

  1. I take the container with this command: podman run -d -p 8080:8080 --name myhttp docker://registry.access.redhat.com/ubi8/httpd-24
  2. I stop the container with the ID CONTAINER I get with podman ps
  3. I try to run the container again this way: podman run -d -p 8080:8080 --name myhttp
  4. I get the error.

Describe the results you received

I always have the Error: requires at least 1 arg(s), only received 0 message when I do podman run, even with the ti argument.

Describe the results you expected

I hope to have the podman run command working correctly or at least an explanation of what I'm doing wrong.

podman info output

host:
  arch: amd64
  buildahVersion: 1.32.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.8-2.1.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.8, commit: unknown'
  cpuUtilization:
    idlePercent: 95.69
    systemPercent: 0.84
    userPercent: 3.47
  cpus: 16
  databaseBackend: boltdb
  distribution:
    distribution: opensuse-microos
    version: "20231001"
  eventLogger: journald
  freeLocks: 2034
  hostname: king-suse
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.5.4-1-default
  linkmode: dynamic
  logDriver: journald
  memFree: 3835781120
  memTotal: 33370398720
  networkBackend: cni
  networkBackendInfo:
    backend: cni
    dns: {}
    package: |-
      cni-1.1.2-2.5.x86_64
      cni-plugins-1.3.0-1.1.x86_64
    path: /usr/libexec/cni
  ociRuntime:
    name: runc
    package: runc-1.1.9-1.1.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.1.9
      commit: v1.1.9-0-gccaecfcbc907
      spec: 1.0.2-dev
      go: go1.21.1
      libseccomp: 2.5.4
  os: linux
  pasta:
    executable: ""
    package: ""
    version: ""
  remoteSocket:
    exists: false
    path: /run/user/1000/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: /etc/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.1-1.1.x86_64
    version: |-
      slirp4netns version 1.2.1
      commit: unknown
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.4
  swapFree: 8589930496
  swapTotal: 8589930496
  uptime: 0h 32m 7.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.opensuse.org
  - registry.suse.com
  - docker.io
store:
  configFile: /home/edu/.config/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 0
    stopped: 4
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/edu/.local/share/containers/storage
  graphRootAllocated: 2047870308352
  graphRootUsed: 481188868096
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 4
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/edu/.local/share/containers/storage/volumes
version:
  APIVersion: 4.7.0
  Built: 1695945600
  BuiltTime: Fri Sep 29 02:00:00 2023
  GitCommit: ""
  GoVersion: go1.21.1
  Os: linux
  OsArch: linux/amd64
  Version: 4.7.0

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

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

@cold-distance cold-distance added the kind/bug Categorizes issue or PR as related to a bug. label Oct 4, 2023
@umohnani8
Copy link
Member

Hi @cold-distance, the podman run command is used to create and run a command in a new container - that is why it works fine the first time for you as you are running a new container.
When you stop a container, the container still exists in the podman storage, you can view all containers (running and stopped) with podman ps -a. You should see your myhttp container there.
To run an existing container, you need to use the podman start command. So for your scenario you would do podman start myhttp.

So podman run is for running new containers and will always require an image name, hence the error you are seeing that 1 arg is required. The podman start command is for running existing containers. I ran through your example given below

➜  podman git:(main) ✗ podman run -d -p 8080:8080 --name myhttp docker://registry.access.redhat.com/ubi8/httpd-24
3405b9bf4f240bc6cdd7a19bcc606598f5c1eb3700d11288e1f3aaf5fef4b4bf
➜  podman git:(main) ✗ podman ps
CONTAINER ID  IMAGE                                            COMMAND               CREATED        STATUS        PORTS                   NAMES
3405b9bf4f24  registry.access.redhat.com/ubi8/httpd-24:latest  /usr/bin/run-http...  2 seconds ago  Up 2 seconds  0.0.0.0:8080->8080/tcp  myhttp
➜  podman git:(main) ✗ podman stop myhttp
myhttp
➜  podman git:(main) ✗ podman ps -a
CONTAINER ID  IMAGE                                            COMMAND               CREATED        STATUS                    PORTS                   NAMES
3405b9bf4f24  registry.access.redhat.com/ubi8/httpd-24:latest  /usr/bin/run-http...  8 seconds ago  Exited (0) 2 seconds ago  0.0.0.0:8080->8080/tcp  myhttp
➜  podman git:(main) ✗ podman start myhttp 
myhttp
➜  podman git:(main) ✗ podman ps
CONTAINER ID  IMAGE                                            COMMAND               CREATED         STATUS        PORTS                   NAMES
3405b9bf4f24  registry.access.redhat.com/ubi8/httpd-24:latest  /usr/bin/run-http...  15 seconds ago  Up 2 seconds  0.0.0.0:8080->8080/tcp  myhttp

Closing this issue as it is not a bug, please reopen if you have further issues.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Jan 3, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

No branches or pull requests

2 participants