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.

Sign up for GitHub

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

Jump to bottom

podman generate systemd creates incorrect WantedBy for user services #5423

Closed
wdouglascampbell opened this issue Mar 8, 2020 · 5 comments · Fixed by #5427
Closed

podman generate systemd creates incorrect WantedBy for user services #5423

wdouglascampbell opened this issue Mar 8, 2020 · 5 comments · Fixed by #5427
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

@wdouglascampbell
Copy link

/kind bug

Description

I'm using podman to generate a systemd service file. I am planning to run the container rootless and use systemd to automatically start the container.

I have enabled linger.

Steps to reproduce the issue:

  1. Generate systemd.
podman generate systemd -n postfix > ~/.config/systemd/user/container-postfix.service
  1. Reload User Service Units.
systemctl --user daemon-reload
  1. Enable Service.
systemctl --user enable container-postfix.service
  1. Reboot

Describe the results you received:

No attempt was made to start the container on reboot.

Describe the results you expected:

Container start attempted on boot.

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

When I edit the container-postfix.service file and change WantedBy line from:

WantedBy=multi-user.target

to:

WantedBy=default.target

and reload the configuration, re-enable, etc and reboot the container runs on boot.

Referencing https://wiki.archlinux.org/index.php/Systemd/User#Writing_user_units it seems to indicate that User Service Unit files should have WantedBy=default.target

Should podman provide an option to specify how to generate the service file?

Output of podman version:

Version:            1.8.0
RemoteAPI Version:  1
Go Version:         go1.13.6
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.6
  podman version: 1.8.0
host:
  BuildahVersion: 1.13.1
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.10-2.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.10, commit: 6b526d9888abb86b9e7de7dfdeec0da98ad32ee0'
  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: 3505111040
  MemTotal: 4121415680
  OCIRuntime:
    name: runc
    package: runc-1.0.0-102.dev.gitdc9208a.fc31.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc10
      commit: 96f6022b37cbe12b26c9ad33a24677bec72a9cc3
      spec: 1.0.1-dev
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 1
  eventlogger: journald
  hostname: localhost
  kernel: 5.4.17-200.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: 29m 25.87s
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /var/home/core/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.5-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /var/home/core/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 2
  RunRoot: /run/user/1000/containers
  VolumePath: /var/home/core/.local/share/containers/storage/volumes

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

VirtualBox, Fedora CoreOS
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Mar 8, 2020
@mheon
Copy link
Member

mheon commented Mar 8, 2020

@vrothberg PTAL

@vrothberg
Copy link
Member

Thanks for opening the issue, @wdouglascampbell! I will have a look at it asap.

@vrothberg vrothberg mentioned this issue Mar 9, 2020
Merged
@vrothberg
Copy link
Member

I opened #5427 to address the issue. I couldn't reproduce your issues in my VMs but tested #5427 successfully for system and user services.

vrothberg added a commit to vrothberg/libpod that referenced this issue Mar 9, 2020
@vrothberg
generate systemd: add default.target to INSTALL
220f9a7 
When enabling a systemd service we can specify which target will start
it by specifying it in the `[INSTALL]` section.  In case of root, this
is commonly set to `multi-user.target` which is used to start other
essential system services such as the network manager, D-BUS and more.

However, the `multi-user.target` is not enough on all systems,
especially when running rootless and enabling user services.  Multiple
users have reported issues that there isn't even an attempt to start the
service.

Setting the INSTALL target to `default.target` will fix the rootless
case.  However, `default.target` may vary among systems.  Fedora
Workstation, for instance, sets the `default.target` to the graphical
target (i.e., runlevel 5) while Fedora Server sets it to
`multi-user.target` which is on runlevel 2 and hence way earlier in the
startup sequence.

As INSTALL allows for specifying multiple INSTALL targets, we can set it
to `multi-user.target` to continue supporting existing workloads AND to
`default.target` which MAY redundantly attempt to start it at a later point;
effectively a NOP for the root case and essential for rootless.

Fixes: containers#5423
Signed-off-by: Valentin Rothberg <[email protected]>
@wdouglascampbell
Copy link
Author

I opened #5427 to address the issue. I couldn't reproduce your issues in my VMs but tested #5427 successfully for system and user services.

Yep. Just got to test adding the WantedBy=default.target to what was already generated and that works. Thanks!

@vrothberg
Copy link
Member

Wonderful, thanks for testing!

snj33v pushed a commit to snj33v/libpod that referenced this issue May 31, 2020
@vrothberg @snj33v
generate systemd: add default.target to INSTALL
20f7235 
When enabling a systemd service we can specify which target will start
it by specifying it in the `[INSTALL]` section.  In case of root, this
is commonly set to `multi-user.target` which is used to start other
essential system services such as the network manager, D-BUS and more.

However, the `multi-user.target` is not enough on all systems,
especially when running rootless and enabling user services.  Multiple
users have reported issues that there isn't even an attempt to start the
service.

Setting the INSTALL target to `default.target` will fix the rootless
case.  However, `default.target` may vary among systems.  Fedora
Workstation, for instance, sets the `default.target` to the graphical
target (i.e., runlevel 5) while Fedora Server sets it to
`multi-user.target` which is on runlevel 2 and hence way earlier in the
startup sequence.

As INSTALL allows for specifying multiple INSTALL targets, we can set it
to `multi-user.target` to continue supporting existing workloads AND to
`default.target` which MAY redundantly attempt to start it at a later point;
effectively a NOP for the root case and essential for rootless.

Fixes: containers#5423
Signed-off-by: Valentin Rothberg <[email protected]>
@giuseppe giuseppe mentioned this issue Nov 6, 2020
Closed
@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.
Assignees
No one assigned
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
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

generate systemd: add default.target to INSTALL containers/podman
4 participants
@wdouglascampbell @mheon @vrothberg @openshift-ci-robot