plugin/hooks: engine MonitorContainer method to track container proc

[bauerm97]

The MonitorContainer function of the Engine interface is called from the parent process of the container process. This process (and consequently this function) acts as the CHILD_SUBREAPER process, and is able to monitor the actions of its descendant procs. In internal/pkg/runtime/engines/engines.go:

// MonitorContainer is called in master once the container proc has been spawned. It
// will typically block until the container proc exists.
MonitorContainer(int, chan os.Signal) (syscall.WaitStatus, error)

I see two main strategies we can employ to implement a hook of this type:

1. Completely override the current engine's MonitorContainer function, removing the engine's implementation from the workflow entirely. This may be the simpler path forward, and might provide more flexibility to developers
2. Add a hook within the engine's specific MonitorContainer function which preforms some specific subset of the role of the MonitorContainer stage. For instance, this hook may only have a reference to the PID of the contained proc and serve to only observe the container, rather than also preforming duty as the child subreaper

cc @ArangoGutierrez @cclerget

[ArangoGutierrez]

+1

[cclerget]

@bauerm97 Regarding 1, while it give flexibility is rather dangerous and could make Singularity behave in unexpected ways, the only use case I see where 1 could be required is to integrate a container tracer requiring call to wait4 to catch ptrace signals, the other use cases are mainly to implement various statistic "tooling".

Additionally master process act as a signal proxy and can't be signaled directly in order to trigger container cleanup, except unblockable signals all others are propagated to main container process.

It doesn't always act as a child subreaper, eg: when PID namespace is enabled.

For stability I think most use cases should be fine with second approach, by running plugin hook as a goroutine and providing parameter like signals received over channel, pid ...

[carterpeel]

Hello,

This is a templated response that is being sent out to all open issues. We are working hard on 'rebuilding' the Singularity community, and a major task on the agenda is finding out what issues are still outstanding.

Please consider the following:

1. Is this issue a duplicate, or has it been fixed/implemented since being added?
2. Is the issue still relevant to the current state of Singularity's functionality?
3. Would you like to continue discussing this issue or feature request?

Thanks, Carter

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in over 60 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[pedroalvesbatista]

@bauerm97 We're looking into the issue carefully, soon will bring to community and discuss ways to better solve as well address this. Thankyou for keeping the interest in the subject.

[kmuriki]

Migrated to the new Apptainer repo https://github.com/apptainer/apptainer/issues/1160