Add a retry on webui service for making sure it will boot up always #1884
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On my testing box, this openqa-webui service can't boot up with system boot. even 'systemctl enable openqa-webui' is done. I saw the comments said our API a little bit expensive, so I guess might be something isn't ready on first time trying. If adding this retry opportunity, service could start up successful.
|
why is not starting up? It shouldn't fail to startup to begin with. |
|
|
This is on boot, right? |
|
Yes, on boot it's failed. |
Codecov Report
@@ Coverage Diff @@
## master #1884 +/- ##
==========================================
- Coverage 90.58% 90.51% -0.07%
==========================================
Files 148 148
Lines 10247 10247
==========================================
- Hits 9282 9275 -7
- Misses 965 972 +7
Continue to review full report at Codecov.
|
|
Can you show us the full log in the case it fails to start? ( |
Sorry, I using a wrong cmdline,,,this is full log: |
|
Service dependence issue? |
|
Hi, I upgrade all openQA and perl to the latest development version. Issue be fixed. |
|
If the issue is fixed for you that's good. @coolo, still restart on fail might be good? Also, does multi-user.target ensure network is up? Sounds like the same issue we had on openqaworker4@o3 |
|
I find restart=on-failure a workaround for things we should fix, so I'm kind of against it. multi-user.target ensures network is up, but we're part of it (wantedby) not behind it. |
|
Sure, so the really strict hard requirements would be IIUC but I think this would delay the boot further waiting for DHCP to get adresses from outside, etc. As you said: The problem should be fixed in the code itself to be resilient |
|
And what's the difference between systemd waiting for the network and openqa waiting for the network? |
|
I guess no difference for a server but I am not sure for a desktop system if that would mean network->openQA->(some other target)->user can work? |
|
Desktop users can work if the desktop is up - if they want to work with openqa, they will have to wait for it to be up, no matter where the delay is. |
|
I don't see that as wanted - especially not as boot order workaround |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On my testing box, this openqa-webui service can't boot up with
system boot. even 'systemctl enable openqa-webui' is done.
I saw the comments said our API a little bit expensive, so I guess
might be something isn't ready on first time trying.
If adding this retry opportunity, service could start up successful.