On Tue, 2019-05-07 at 13:33 +0200, Farkas Levente wrote: > On 5/6/19 4:11 PM, Brent Baude wrote: > > On Mon, 2019-05-06 at 13:16 +0200, Farkas Levente wrote: > > > On 5/2/19 9:20 PM, Brent Baude wrote: > > > > On Thu, 2019-05-02 at 16:12 +0200, Farkas Levente wrote: > > > > > - Create a systemd service file on the host for the > > > > > healthcheck, > > > > > - Create a systemd timer file on the host for the > > > > > healthcheck. > > > > > > > > > > > > > Just for the record, healthchecks are optional. The systemd > > > > service > > > > and timer files are created automatically for you with podman > > > > and > > > > are > > > > considered to be transient in nature. That means if the system > > > > is > > > > rebooted, that timer and service are deleted. If the container > > > > is > > > > started again, they are recreated. > > > > > > does it means the recommended way to create one systemd service > > > file > > > for > > > the container and in this service the ExecStart's podman should > > > have > > > to > > > be a --healthcheck-command parameter (and may be more) and use > > > the > > > podman generated transient timer or service for healtcheck? > > > > > > and in this case in case of failure who and how will restart the > > > main > > > service? > > > > > > > Farkas, > > > > I'm having trouble understanding your question. The use of systemd > > to > > control a container and the use of systemd to provide health checks > > are > > mutually exclusive. You do not need to put anything healthcheck > > related in your systemd file that controls the container. > > first of all my biggest problem the lack of documentation. IMHO it's > not > the best solution to read blog to get the docs. eg:
I'm sorry you feel that way. There is no obvious way to document healthchecks as it really crosses multiple functions. The healthcheck command only executes the healthcheck and does not set them up. > > https://github.com/containers/libpod/blob/master/docs/podman-run.1.md > which seems to me the latest up-to-date manual said: > -------------------------------------- > --healthchech="" > > Set or alter a healthcheck for a container. The value must be > of > the format of: > > [OPTIONS] CMD command > > where options can be any of the follow: > * --interval=DURATION (default: 30s) > * --timeout=DURATION (default: 30s) > * --start-period=DURATION (default: 0s) > * --retries=N (default: 3) > -------------------------------------- > not to mention the --healthchech typo since it's just a simple typo. There is an open PR to fix this typo. > and > it seems to copied from docker. > It is not a copy of docker. Docker does not support these options on the run/create command line. Similar, yes indeed. But as others can attest to, I really struggled with typing healthcheck and made typos for it frequently. > while your blog: > https://developers.redhat.com/blog/2019/04/18/monitoring-container-vitality-and-availability-with-podman/ > said > --healthcheck-command which is not in the man > --healthcheck-start-period etc not an option for --healthcheck > > so which one is the valid? > while both are a few weeks old still not consistent and can't help. > I finally understand what you were getting at. I have updated the create and run man pages. You can see https://github.com/containers/libpod/pull/3076 as the fix. > > back to my original question. assume I don't use kubernetes or any > other > orchestration and just wanna setup a host (atomic or normal) with a > few > predefined containers. starting and running these containers with > systemd. > As I said in the prior responses, healthchecks and container control are mutually exclusive. If all you want to do is start, stop, restart containers with systemd, then try out the podman generate systemd command and add the results to your systemd services. > in this case should i add a healthcheck service and timer unit or use > the transient podman generated service and times? > > > ps. as a side note to a long waiting feature in docker's healthcheck > to > be able to restart or exit the container which health status if > failed. > even if docker always postpone this request it'd be nice to add to We have been thinking about this too. Hang tight! > podman like --all and -l. > Responses inline.
