Closed jwreagor closed 6 years ago
I'm taking my time testing this since I'll be introducing behavior into the supervisor process. I already have plans to change my original implementation under this WIP PR. I've found some optimizations but also weird behavior (dup signals passing).
Latest commits include fixes from master as well as simplifying the supervisor logic. I'll perform final testing tomorrow.
Alright, I think this is baked enough. Couple things to note...
I'll get CR of this next week.
/cc @stack72 for CR, I'll test on my own one last time and get this out the door this week.
Going to test this one last time and get this merged today.
Going to close this PR, do the squash manually, and open a second for the merge.
Ref: #513
This PR implements the process outlined in the tracking issue. I've also included the ability for running jobs to create an environment variable including their PID (
CONTAINERPILOT_<name>_PID
) as well as both the supervisor and normal worker process signal handlers. So far, the functionality is working out great and you can fire jobs based on a container receiving a specific signal (or CP process itself). Obviously this is more of a scheduler based feature for CP and not something useful for the Triton audience.I'm still testing this and looking to make sure nothing that I've changed is going to cause havoc to the supervisor process.