-
Notifications
You must be signed in to change notification settings - Fork 32
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
Wait for epair interface to become available #201
Comments
Looking into the start/stop logic, I understand why this happened in the past (before #200). I'll open a new task, but to leave this open for discussion for the time being. |
Hi, thanks for reporting this corner case. Is the delay in the creation of epair (AKA |
The FreeBSD |
What I perceived might have been caused by #202, but for robustness, implementing this would still make sense (and is also relatively easy using netwait). I think it should include some sort of timeout. |
it could be that epair_cleanup deleted the epair couple just created by the new start. |
This applies to pots without an rc script. Closes bsdpot#201 Fixes bsdpot#203
This applies to pots without an rc script. Closes bsdpot#201 Fixes bsdpot#203
This applies to pots without an rc script. Closes bsdpot#201 Fixes bsdpot#203
This applies to pots without an rc script. Closes bsdpot#201
This applies to pots without an rc script. Closes bsdpot#201
This applies to pots without an rc script. Closes bsdpot#201
This applies to pots without an rc script. Closes #201
Is your feature request related to a problem? Please describe.
Prior to applying #200 I experienced a few occasions of the epair interface not being available inside of the pot/jail when tinirc executed - it became available a few seconds later though.
I suspect that this was due to some
pot start
/pot stop
overlaps that were removed or at least made a lot less likely by the changes in that pull request. As I can't rule out that this is something that could happen under other circumstances as well (read: it's possible in general), it would be good to have a mechanism to deal with it.Describe the feature you'd like to have
A simple check with a timeout that waits for the epair interface to show up before
ifconfig
+route add default
are called. Exit with an error code in case it doesn't become available. Update: This could be done in /tmp/tinirc, or maybe even better inside of pot before running pot.cmd (e.g., aftersleep 1234
and beforejexec $cmd
).I'm not 100% sure if that would cut it though (assuming there is still a possibility that some stray
pot stop
/cleanup messing with the epair interface) or if it would mask a lower level problem. Like said above, when using #200 I haven't seen it yet, but my test cases weren't particularly complex.Happy to implement it myself, but would like to have a discussion first.
Describe potential alternatives or workaround you've considered (if any)
Use a handcrafted tinirc and override pot.cmd?!
The text was updated successfully, but these errors were encountered: