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 will duplicate some of the parameters of a container executed with a systemd unit file by generating it again #9776

Closed
unknowndevQwQ opened this issue Mar 21, 2021 · 5 comments · Fixed by #9848
Assignees
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

@unknowndevQwQ
Copy link
Contributor

unknowndevQwQ commented Mar 21, 2021

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

/kind bug

Description

podman will duplicate some of the parameters of a container executed with a systemd unit file by generating it again

Steps to reproduce the issue:

  1. Run the container
    # podman run --name t --rm busybox sleep 810

  2. generate systemd unit files
    # podman generate systemd --files --new --name t

  3. stop the container started in the first step
    # podman stop t

  4. Start the container with the unit file generated in step 2
    # cp *.service -t /etc/systemd/system && systemctl start container-t

  5. repeat step 2

Describe the results you received:

In the container: the --common-pidfile, --cidfile, --cgroups arguments repeat the arguments already in the previous systemd unit file on top of the podman generation
In pods: the --infra-conmon-pidfile parameter repeats the parameters of the last systemd unit file on top of those generated by podman

Describe the results you expected:

If in a container: only one podman-generated --conmon-pidfile, --cidfile, --cgroups parameter
If in a pod: only one podman-generated --infra-conmon-pidfile parameter

Additional information you deem important (e.g. issue happens only occasionally):
none
Output of podman version:

Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.16
Git Commit:   c640670e85c4aaaff92741691d6a854a90229d8d
Built:        Sun Feb 21 23:29:46 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.4
  cgroupManager: systemd
  cgroupVersion: v1
  conmon:
    package: /usr/bin/conmon is owned by conmon 1:2.0.26-1
    path: /usr/bin/conmon
    version: 'conmon version 2.0.26, commit: 0e155c83aa739ef0a0540ec9f9d265f57f68038b'
  cpus: 3
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  hostname: arch
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.10.16-arch1-1
  linkmode: dynamic
  memFree: 1468776448
  memTotal: 6212612096
  ociRuntime:
    name: runc
    package: /usr/bin/runc is owned by runc 1.0.0rc93-1
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc93
      commit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
      spec: 1.0.2-dev
      go: go1.15.7
      libseccomp: 2.5.1
  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
    selinuxEnabled: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 6442442752
  swapTotal: 6442442752
  uptime: 21m 22.4s
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 5
    paused: 0
    running: 5
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 31
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1613921386
  BuiltTime: Sun Feb 21 23:29:46 2021
  GitCommit: c640670e85c4aaaff92741691d6a854a90229d8d
  GoVersion: go1.16
  OsArch: linux/amd64
  Version: 3.0.1

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

Repository      : community
Name            : podman
Version         : 3.0.1-2
Description     : Tool and library for running OCI-based containers in pods
Architecture    : x86_64
URL             : https://github.com/containers/libpod
Licenses        : Apache
Groups          : None
Provides        : None
Depends On      : cni-plugins  conmon  containers-common  device-mapper  iptables  libseccomp  runc  slirp4netns  libsystemd  fuse-overlayfs  libgpgme.so=11-64
Optional Deps   : podman-docker: for Docker-compatible CLI
                  btrfs-progs: support btrfs backend devices
                  catatonit: --init flag support
                  crun: support for unified cgroupsv2
Conflicts With  : None
Replaces        : None
Download Size   : 18.65 MiB
Installed Size  : 75.64 MiB
Packager        : Morten Linderud <[email protected]>
Build Date      : Sun Feb 21 23:29:46 2021
Validated By    : MD5 Sum  SHA-256 Sum  Signature

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

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

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Mar 21, 2021
@Luap99
Copy link
Member

Luap99 commented Mar 21, 2021

Why do you want to regenerate the same file when you already have a running systemd unit?
Also the new generated unit file should still be working. Specifying the same cli argument several times is valid, only the last value will be used.

@unknowndevQwQ
Copy link
Contributor Author

Why do you want to regenerate the same file when you already have a running systemd unit?
Also the new generated unit file should still be working. Specifying the same cli argument several times is valid, only the last value will be used.

I only updated the scripts that podman 2.0.4 generated

@Luap99
Copy link
Member

Luap99 commented Mar 21, 2021

This makes sense. We already check for the --name flag so checking for other flags should be easy.

@unknowndevQwQ
Copy link
Contributor Author

This makes sense. We already check for the --name flag so checking for other flags should be easy.

wdym

@Luap99
Copy link
Member

Luap99 commented Mar 22, 2021

I was wondering why you would want to do this. Updating the files after a podman upgrade sounds reasonable to me.
We have already a check in the generating code for the --name and --replace flag so adding the flags you mentioned should only need a small change to the code.

@Luap99 Luap99 self-assigned this Mar 28, 2021
Luap99 pushed a commit to Luap99/libpod that referenced this issue Mar 28, 2021
podman generate systemd --new inserts extra idfile arguments. The
generated unit can break when the user did provide their own idfile
arguments as they overwrite the arguments added by generate systemd.
This also happens when a user tries to generate the systemd unit on
a container already create with a --new unit. This should now
create a identical unit. The solution is to remove all user provided
idfile arguments.

This commit also ensures that we do not remove arguments that are part
off the containers entrypoint.

Fixes containers#9776

Signed-off-by: Paul Holzinger <[email protected]>
mheon pushed a commit to mheon/libpod that referenced this issue Mar 29, 2021
podman generate systemd --new inserts extra idfile arguments. The
generated unit can break when the user did provide their own idfile
arguments as they overwrite the arguments added by generate systemd.
This also happens when a user tries to generate the systemd unit on
a container already create with a --new unit. This should now
create a identical unit. The solution is to remove all user provided
idfile arguments.

This commit also ensures that we do not remove arguments that are part
off the containers entrypoint.

Fixes containers#9776

Signed-off-by: Paul Holzinger <[email protected]>
jmguzik pushed a commit to jmguzik/podman that referenced this issue Apr 26, 2021
podman generate systemd --new inserts extra idfile arguments. The
generated unit can break when the user did provide their own idfile
arguments as they overwrite the arguments added by generate systemd.
This also happens when a user tries to generate the systemd unit on
a container already create with a --new unit. This should now
create a identical unit. The solution is to remove all user provided
idfile arguments.

This commit also ensures that we do not remove arguments that are part
off the containers entrypoint.

Fixes containers#9776

Signed-off-by: Paul Holzinger <[email protected]>
@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 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 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

Successfully merging a pull request may close this issue.

3 participants