Skip to content
New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom

start-cleanup/stop can interfere with each other #152

Closed
pizzamig opened this issue Jun 19, 2021 · 3 comments
Closed

start-cleanup/stop can interfere with each other #152

pizzamig opened this issue Jun 19, 2021 · 3 comments
Assignees
@pizzamig
Labels
feature

Comments

@pizzamig
Copy link
Collaborator

pizzamig commented Jun 19, 2021 •
edited
Loading

Describe the feature you'd like to have
pot start contains a cleanup feature, if start fails, but it's also used when a the jail has a blocking start command with non persistent jails.
In this second case, pot stop and the start cleanup (who also calls pot stop) can mix their effects and some unexpected behavior can happen (i.e. failing to destroy the epair twice)

First, make the execution sequential would help to avoid the code to interfere with each other.
Moreover, it would be useful to relax the assumptions made in the code, make it a bit more robust

As discussed in #150
@pizzamig pizzamig self-assigned this Jun 19, 2021
@grembo
Copy link
Collaborator

grembo commented Jun 19, 2021

Serializing is definitely better than having the code execute in parallel.
Ideally, we would ensure that the commands in stop only run once (at least things like post hooks).

How this will play out exactly might also depend on how we change jail start up (e.g., jail start command vs. jexec command).

grembo added a commit to grembo/pot that referenced this issue Jun 19, 2021
@grembo
Prevent stopping non-persistent jails twice
fe9525d 
This aims to address bsdpot#152.

The problem at hand isn't really to prevent `pot stop` from
running in parallel (this could be handled on a global level),
but to prevent running "_js_stop" in `pot start`, after a
non-persistent jail was stopped.

The solution is very simple, as the use case this is about is:
1. pot stop is called
2. jail -r is called
3. pot start continues and calls "_js_stop"

By removing a file (and touching it when running "_js_stop")
this can be prevented without having to use real lock files.

Note: Given the number of files pot creates, it might make sense
to start using a subdirectory called _/tmp/pot_.
@grembo grembo mentioned this issue Jun 19, 2021
Merged
pizzamig added a commit that referenced this issue Jun 20, 2021
@grembo @pizzamig
Prevent stopping non-persistent jails twice (#155)
fce2c9d 
This aims to address #152.

The problem at hand isn't really to prevent `pot stop` from
running in parallel (this could be handled on a global level),
but to prevent running "_js_stop" in `pot start`, after a
non-persistent jail was stopped.

The solution is very simple, as the use case this is about is:
1. pot stop is called
2. jail -r is called
3. pot start continues and calls "_js_stop"

By removing a file (and touching it when running "_js_stop")
this can be prevented without having to use real lock files.

Note: Given the number of files pot creates, it might make sense
to start using a subdirectory called _/tmp/pot_.

Co-authored-by: Luca Pizzamiglio <pizzamig@FreeBSD.org>
@grembo
Copy link
Collaborator

grembo commented Jul 24, 2021

@pizzamig Do you think #155 is sufficient to resolve this?

@pizzamig
Copy link
Collaborator Author

Yes, I think is good enough.
I'll close it

# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees

@pizzamig pizzamig

Labels
feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pizzamig @grembo