Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add prestart/poststop hooks to runc #160

Merged
merged 2 commits into from
Sep 24, 2015

Conversation

mrunalp
Copy link
Contributor

@mrunalp mrunalp commented Jul 28, 2015

The spec.go commit will be taken out once merged upstream.

Signed-off-by: Mrunal Patel mrunalp@gmail.com

@mrunalp
Copy link
Contributor Author

mrunalp commented Jul 28, 2015

@LK4D4 @crosbymichael ping

@ashahab-altiscale
Copy link
Contributor

@mrunalp Not sure if this is a related question, but can I get the pid of the container when I'm running a pre-start hook? Also, can I be running in the host's namespace?

@LK4D4
Copy link
Contributor

LK4D4 commented Aug 3, 2015

@ashahab-altiscale Yes for both I think. Cause it's like whole idea :D

@marcosnils
Copy link
Contributor

@LK4D4 @mrunalp sorry for the ignorance, but isn't this the same as doing some command ; runc config.json; some other command in a *nix system?.

I know that if it's included in runc it will be agnostic to the platform and becomes part of the spec but what are the advantages/use cases of doing it natively rather than from the OS?

OT: Is there a place where runc features / roadmap is available to the community?. I'd be great of some users can actually take a look into it and maybe leave some comments which will make the product better.

Thanks!.

@marcosnils
Copy link
Contributor

BTW: This doesn't have any tests?

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 3, 2015

@marcosnils Actually, there is a difference and a reason why we introduce the prestart hook :)
The prestart hook is run after the container process is up (cloned into new namespaces) but before the user command (for e.g. bash) is executed. That allows someone to do something useful in the namespaces of the container. See opencontainers/runtime-spec#34 for more details.

@marcosnils
Copy link
Contributor

@mrunalp got it. My impression was correct, I though that the hooks were executed inside the container namespace. I still have to look into runc code a bit more to understand it's components.

Thanks!.

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 4, 2015

Rebased.

// Call the poststop hooks
statePath := p.container.stateFilePath()
for _, poststopcmd := range p.poststop {
// TODO: Log the errors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return errors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 5, 2015

Added test.

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 6, 2015

@crosbymichael @LK4D4 PTAL

@dqminh
Copy link
Contributor

dqminh commented Aug 7, 2015

LGTM

@estesp
Copy link
Contributor

estesp commented Aug 12, 2015

+1 Would love to see this get in soon so we can continue re-instatement of user namespace support merging into Docker.

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 18, 2015

Rebased.

@mrunalp mrunalp mentioned this pull request Aug 19, 2015
@ashahab-altiscale
Copy link
Contributor

+1 Lets get this merged!

On Tue, Aug 18, 2015 at 3:01 PM, Mrunal Patel notifications@github.com
wrote:

Rebased.


Reply to this email directly or view it on GitHub
#160 (comment).

@dqminh
Copy link
Contributor

dqminh commented Aug 20, 2015

Still LGTM

ping @LK4D4 @crosbymichael

@@ -271,6 +294,27 @@ func (p *initProcess) createNetworkInterfaces() error {
return nil
}

func runCmd(command configs.Command, statePath string) error {
cmd := exec.Command(command.Path, command.Args[:]...)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exec.Command doesn't let you set argv[0] independently of command.Path, which seemed like something desired by the spec (but the spec isn't clear on how it should be handled).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mrunalp is there a reason to use exec.Command instead of populating exec.Cmd directly with the args ?
As @wking indicated exec.Command forces the argv[0] to be the path : https://golang.org/src/os/exec/exec.go?s=3999:4044#L112 , and hence command.Args can only occupy argv[1]...

IMO, the following is better

-       cmd := exec.Command(command.Path, command.Args[:]...)
+       cmd := exec.Cmd{
+               Path: command.Path,
+               Args: command.Args[:],
+       }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@wking
Copy link
Contributor

wking commented Aug 20, 2015

On Mon, Aug 03, 2015 at 11:02:57AM -0700, Mrunal Patel wrote:

The prestart hook is run after the container process is up (cloned
into new namespaces) but before the user command (for e.g. bash) is
executed. That allows someone to do something useful in the
namespaces of the container.

If so, I think it's probably worth clarifing that in the spec. It
seems like you could handle that by adjusting process.args in your
config to call a script that handled in-container setup, execution,
and teardown. I though the pre-start hooks would be run from the host
environment after the container was setup but before the container's
process.args was launched, and then the post-stop hooks would be run
from the host's environment after the process.args process was
stopped, but before any explicit environment teardown commenced.

For example, the host-environment semantics would let you manipulate
the container itself, which you may not have permission to do from
within the container.

I'm not even sure how in-container hooks would work, since the hook's
path is spec'ed to refer to the host filesystem 1, but inside the
container we'd be using the container's filesystem, no?

@LK4D4
Copy link
Contributor

LK4D4 commented Aug 25, 2015

ping @Madhu @mrjana for comments

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 28, 2015

@LK4D4 @crosbymichael ping
@mavenugo did confirm on IRC that this works for him with the changes he suggested.

@crosbymichael
Copy link
Member

@mrunalp do we want to wait on the state PR in specs so that we have something to provide the hook?

@mrunalp
Copy link
Contributor Author

mrunalp commented Aug 28, 2015

@crosbymichael works for me. (We do pass state in this PR but it isn't standardized).

@estesp
Copy link
Contributor

estesp commented Sep 7, 2015

Now that the state PR is completed, do you have time to update this @mrunalp?

@wking
Copy link
Contributor

wking commented Sep 7, 2015

On Mon, Sep 07, 2015 at 02:26:36PM -0700, Phil Estes wrote:

Now that the state PR is completed, do you have time to update this
@mrunalp?

Things that still have to happen:

a. rebase this to pull in the state.json specified by
opencontainers/runtime-spec#87
b. decide on args[0] handling in the spec (opencontainers/runtime-spec#118)
c. possibly rebase this to pull in an alternative args[0] approach
(e.g. Python's optional-path approach from 1)
d. final review and merge of this PR

(b) is external to this PR, so I don't see any need to rush forward
with (a). But (a) and (b/c) are very orthogonal issues, so if we want
to handle (a) before (b/c) that's probably an efficient use of
development time too.

@wking
Copy link
Contributor

wking commented Sep 7, 2015

On Thu, Aug 20, 2015 at 10:40:11AM -0700, W. Trevor King wrote:

Mon, Aug 03, 2015 at 11:02:57AM -0700, Mrunal Patel:

The prestart hook is run after the container process is up (cloned
into new namespaces) but before the user command (for e.g. bash)
is executed. That allows someone to do something useful in the
namespaces of the container.

If so, I think it's probably worth clarifing that in the spec… I
though the pre-start hooks would be run from the host environment
after the container was setup but before the container's
process.args was launched, and then the post-stop hooks would be run
from the host's environment after the process.args process was
stopped, but before any explicit environment teardown commenced.

I still haven't looked over the backing code here, but while testing
hook-based oom_score_adj handling for opencontainers/runtime-spec#115 1, it
seems pretty clear that at least the pre-start hooks are executing in
the host environment (I could write to the host's
/proc/${PID}/oom_score_adj, which is /proc/1/oom_score_adj inside my
PID-namespaced container). Is that enough consensus (me agreeing with
what runC does) to open an opencontainers/specs PR, or do we want
further discussion about the hook execution environment (here or on
the mailing list) before I open a spec PR?

@mrunalp
Copy link
Contributor Author

mrunalp commented Sep 9, 2015

@estesp I am waiting on #242 to go in.

@cyphar
Copy link
Member

cyphar commented Sep 15, 2015

#242 is in. Let's get this merged. 👍:shipit:

@mrunalp
Copy link
Contributor Author

mrunalp commented Sep 15, 2015

Updated the PR to integrate with the libcontainer support.

@mrunalp
Copy link
Contributor Author

mrunalp commented Sep 16, 2015

@LK4D4 @crosbymichael @dqminh PTAL.
Also, do we want to replace HookState by State from spec repository or make it json compatible?

@dqminh
Copy link
Contributor

dqminh commented Sep 16, 2015

LGTM

Also, do we want to replace HookState by State from spec repository or make it json compatible?

Also +1 :-)

@mrunalp
Copy link
Contributor Author

mrunalp commented Sep 23, 2015

Updated to use State from the spec. @crosbymichael @LK4D4 @dqminh PTAL.

@runcom
Copy link
Member

runcom commented Sep 23, 2015

can libcontainer continue to be specs free? even if go get'ing it still requires to pull specs for runc itself I like the configs layer in between and libcontainer users may benefit from having something before specs gets updated, no big deal tho
maybe plans are to integrate specs objs in libcontainer

@crosbymichael
Copy link
Member

Why not keep it json compatible then we don't have to mix the two?

@cyphar
Copy link
Member

cyphar commented Sep 23, 2015

IMO libcontainer should not use the spec, since it's technically an implementation detail of runc and thus independent of the opencontainers spec.

Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
@mrunalp
Copy link
Contributor Author

mrunalp commented Sep 24, 2015

@crosbymichael Updated.

@crosbymichael
Copy link
Member

LGTM

1 similar comment
@LK4D4
Copy link
Contributor

LK4D4 commented Sep 24, 2015

LGTM

LK4D4 added a commit that referenced this pull request Sep 24, 2015
Add prestart/poststop hooks to runc
@LK4D4 LK4D4 merged commit aac9179 into opencontainers:master Sep 24, 2015
stefanberger pushed a commit to stefanberger/runc that referenced this pull request Sep 8, 2017
Modify the capabilities constants to match header files like other constants
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.