issues restarting or stopping systemd service pods

[creich]

due to my tests i encountered several issues using the generated systemd service.
e.g. trying to restart brought the service into the following status:

$ systemctl restart lighttpd-container-pod.service
$ systemctl status lighttpd-container-pod.service
● lighttpd-container-pod.service - lighttpd Podman Container
   Loaded: loaded (/etc/systemd/system/lighttpd-container-pod.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-12-13 14:10:38 EST; 2s ago
  Process: 5639 ExecStop=/usr/bin/podman stop lighttpd (code=exited, status=125)
  Process: 5671 ExecStartPre=/usr/bin/podman rm lighttpd (code=exited, status=1/FAILURE)
 Main PID: 5723 (podman)

[ikke-t]

Hmmm, my podman version 1.4.2-stable2 does not have such -i option. Need to take another look later.

[creich]

i am using podman 1.7.0 atm.
question is, if we should fix it for the lower versions as well and if we do that, how we want to split those solutions. i found the -i option very lean and guess that fixing it another way might become more code.

any preferences on your side?

[ikke-t]

Sorry it took time to come back to this, thanks for your patience. There has been a lot of traveling in between.

I don't see the problem there. I especially used the minus on those fields (=-) to let systemd ignore if the command throws an error. Sure, journalctl will have failed exec code for the line, but it ignores the error. Adding the -i option would lead to same state, right? Only difference that podman would ignore the error. Or am I missing something?

I would be OK to have the -i switch there preferrably once RHEL/CentOS operating systems will have such version of podman that has it. It can't be too long. But is there any benefit seeing the trouble for the time being?

See the "Table 1. Special executable prefixes" on this page, and look for the - operand: https://www.freedesktop.org/software/systemd/man/systemd.service.html

If the executable path is prefixed with "-", an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.

Perhaps I didn't understand the problem?

[ikke-t]

This is the line that you should be looking into, and it's just fine:

Active: active (running)

[jaywryan]

I ran into similar problems and I have made some fixes, I'm not sure that these would be worth having upstream or not. I was trying to run rootless and the systemd unit file was not working as expected and wasn't able to start or stop the pods successfully as the PIDs were not owned by system. I will submit a pull request for the changes I made to help fix this, but I'm not sure if my changes may be breaking or not.