systemd generator: force run container detached if CreateCommand has no detach param

[ttys3]

since we use systemd service Type=forking
when we generated systemd service file using the --new param like

 sudo podman generate systemd --name --new ctrName

we got ExecStart=/usr/bin/podman run --conmon-pidfile ...
if somehow the container's CreateCommand has no -d or --detach param,
podman will run the container in default attached mode.
so systemd will wait the podman command exit until failed with timeout error.

quick reproduce the problem:

sudo podman pull nginxdemos/hello
sudo podman create --name ngxdemo -p 8086:80 nginxdemos/hello
cd /etc/systemd/system/
sudo podman generate systemd --name --new --restart-policy on-failure -t 3 --files ngxdemo
sudo podman rm ngxdemo

sudo systemctl start container-ngxdemo.service
Job for container-ngxdemo.service failed because a timeout was exceeded.
See "systemctl status container-ngxdemo.service" and "journalctl -xe" for details.

how to avoid the problem:

solution 1: merge this PR -_- and everything goes fine

solution 2: warn user to remember add -d when create the container
and user need to do is just add the -d param to the create command:

sudo podman pull nginxdemos/hello
sudo podman create -d --name ngxdemo -p 8086:80 nginxdemos/hello
cd /etc/systemd/system/
sudo podman generate systemd --name --new --restart-policy on-failure -t 3 --files ngxdemo
sudo podman rm ngxdemo
sudo systemctl start container-ngxdemo.service
# everything goes fine

[ttys3]

/assign @mheon

[vrothberg]

Thanks for the contribution!

Unit tests are not happy (see go test -v github.com/containers/libpod/pkg/systemd/generate). Also please add a test to test/e2e/generate_systemd_test.go where we create a container without -d, then generate the output and look for --cgroups=no-conmon -d in the output.

Adding a sentence or two to docs/source/markdown/podman-generate-systemd.1.md would be great to explain why we enforce detaching.

[vrothberg]

Also please explain the changes in the commit message.

[rhatdan]

Thanks @ttys3 Interesting change.

[mheon]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mheon, ttys3

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mheon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mheon]

LGTM once comments from @vrothberg are addressed

[vrothberg]

e2e tests are not yet happy:

[+1126s] [Fail] Podman generate systemd [It] podman generate systemd --new with explicit detaching param in middle
[+1126s] /var/tmp/go/src/github.com/containers/libpod/test/e2e/generate_systemd_test.go:223

[ttys3]

e2e tests are not yet happy:

[+1126s] [Fail] Podman generate systemd [It] podman generate systemd --new with explicit detaching param in middle
[+1126s] /var/tmp/go/src/github.com/containers/libpod/test/e2e/generate_systemd_test.go:223

fixed.
but I see another two tests failed (seems not related to my PR):

special_testing_rootless name:remote Failing after 21m — Task Summary
test fedora-30 name:remote Failing after 25m — Task Summary

[mheon]

F30 remote is a known flake.

Rootless might be a real but. Restarted to see if it was a flake, but wouldn't be surprised if it reoccurs.

[vrothberg]

Another restart :)

[vrothberg]

/lgtm

[edsantiago]

This has broken CI. Is anyone working on a fix?

[vrothberg]

This has broken CI. Is anyone working on a fix?

Entirely my bad as we should have rebased this PR before merging. #5514 is fixing CI.