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

Use of --cidfile prevents a container from starting up #4808

Closed
larsks opened this issue Jan 7, 2020 · 4 comments
Closed

Use of --cidfile prevents a container from starting up #4808

larsks opened this issue Jan 7, 2020 · 4 comments
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

@larsks
Copy link
Contributor

larsks commented Jan 7, 2020

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

/kind bug

Description

"Running containers with podman and shareable systemd services" by @vrothberg suggests the following template for service units that run podman:

[Service]
Restart=on-failure
ExecStartPre=/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid -d alpine:latest top
ExecStop=/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Type=forking
PIDFile=/%t/%n-pid

But podman rm ... does not clean up the --cidfile, and subsequent attempts to start this container will fail with:

Error: container id file exists. Ensure another container is not using it or delete //run/user/1000/tinyproxy.service-cid

This behavior was introduced in #530, but this brings up a variety of problems. If I want to start a container using --cidfile:

  • Do I just use an ExecStartPre to delete --cidfile first? That would seem to lead to the same problem that podman run --cidfile: fail if path exists #530 was designed to fix.
  • Do I make removing the --cidfile part of ExecStop? I guess we can do that, but that means that people using --cidfile will always need to perform an additional cleanup step, regardless of whether they are using systemd units or something else.

It seems like the ideal behavior would be for podman to clean up the --cidfile when the container is removed.

Steps to reproduce the issue:

  1. podman run --cidfile /tmp/cidfile alpine true

  2. podman rm $(cat /tmp/cidfile)

  3. podman run --cidfile /tmp/cidfile alpine true

Describe the results you received:

Error: container id file exists. Ensure another container is not using it or delete /tmp/cidfile

Describe the results you expected:

I expected the container to start the second time.

Output of podman version:

podman version 1.7.0-dev

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.5
  podman version: 1.7.0-dev
host:
  BuildahVersion: 1.11.6
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.2-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.2, commit: 186a550ba0866ce799d74006dab97969a2107979'
  Distribution:
    distribution: fedora
    version: "31"
  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
  MemFree: 1306804224
  MemTotal: 33580802048
  OCIRuntime:
    name: crun
    package: crun-0.10.6-2.fc32git818defc.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6.51-818d
      commit: 818defc6cc809533a305e8a786438dd579660ee8
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 16599216128
  SwapTotal: 16890458112
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: madhatter
  kernel: 5.3.16-300.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 410h 8m 49.05s (Approximately 17.08 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /home/lars/.config/containers/storage.conf
  ContainerStore:
    number: 5
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.2-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.2
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/lars/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 73
  RunRoot: /run/user/1000
  VolumePath: /home/lars/.local/share/containers/storage/volumes

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

podman-1.7.0-0.8.dev.git6c7b6d9.fc32.x86_64
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jan 7, 2020
@mheon
Copy link
Member

mheon commented Jan 7, 2020

@vrothberg PTAL

I recall conversations about making --cidfile remove the file and recreate if it already existed?

@rhatdan
Copy link
Member

rhatdan commented Jan 7, 2020

What does docker do? Does it fail if the cidfile preexists?

@larsks
Copy link
Contributor Author

larsks commented Jan 7, 2020

Huh, I didn't even realize that docker run had a --cidfile option. It looks as if docker run has the same behavior as we currently see in podman.

However, docker rm doesn't have a --cidfile option, while podman rm does. So it may make sense for podman rm --cidfile to remove the cidfile.

This would certainly make writing robust systemd units easier.

@larsks
Copy link
Contributor Author

larsks commented Jan 7, 2020

You know, I see now that the proposed unit is actually explicitly removing the cidfile in ExecStartPre. I guess I missed that? I'm going to close this now as noise...

@larsks larsks closed this as completed Jan 7, 2020
@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 Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
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

4 participants