[ClusterLabs Developers] bundle/docker: zombie process on resource stop

Jan Pokorný jpokorny at redhat.com
Fri Jul 28 03:04:20 EDT 2017


On 27/07/17 17:40 -0500, Ken Gaillot wrote:
> On Thu, 2017-07-27 at 23:26 +0200, Jan Pokorný wrote:
>> On 24/07/17 17:59 +0200, Valentin Vidic wrote:
>>> On Mon, Jul 24, 2017 at 09:57:01AM -0500, Ken Gaillot wrote:
>>>> Are you sure you have pacemaker 1.1.17 inside the container as well? The
>>>> pid-1 reaping stuff was added then.
>>> 
>>> Yep, the docker container from the bundle example got an older
>>> version installed, so mystery solved :)
>>> 
>>>   pacemaker-remote-1.1.15-11.el7_3.5.x86_64
>> 
>> As with docker/moby kind of bundles, pacemaker on host knows when it
>> sets pacemaker_remoted as the command to be run within the container
>> or not, it would be possible for it in such case check whether this
>> remote peer is recent enough to cope with zombie reaping and prevent
>> it from running any resources if not.
> 
> Leaving zombies behind is preferable to being unable to use containers
> with an older pacemaker_remoted installed. A common use case of
> containers is to run some legacy application that requires an old OS
> environment. The ideal usage there would be to compile a newer pacemaker
> for it, but many users won't have that option.

I was talking about in-bundle use case (as opposed to generic
pacemaker-remote one) in particular where it might be preferable
to have such sanity check in place as opposed to hard-to-predict
consequences, such as when the resource cannot be stopped due to
interference with zombies (well, there is whole lot of other issues
with this weak grip on processess, such as the resource agents on
host can get seriously confused by the processes running in the
local containers!).

For the particular, specific use case at hand, it might be reasonable
to require pacemaker-remote version that actually got bundle-ready,
IMHO.

>> The catch -- pacemaker on host cannot likely evalute this "recent
>> enough" part of the equation properly as there was no LRMD protocol
>> version bump for 1.1.17.  Correct?  Any other hints it could use?

-- 
Poki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20170728/131ed087/attachment-0003.sig>


More information about the Developers mailing list