Closed eddiecheng closed 1 year ago
Additional Informations
XOA From sources installed on OS : Debian 11
Latest Commit XCP 8.2.1 with all patches done as at 5th Feb 2023
It looks like the bug with the default value change for requestTimeout
in Node 18.
But it has been fixed already in f6fd1db1ef12633cc5bb8ec8ab5bc84682dd3fe7
Check that your xo-server
is up-to-date and has restarted since this fix.
To be sure your configuration is correct run the following command in xo-server
's directory:
> npx app-conf xo-server . -p http.listenOptions.requestTimeout
86400000
This message is outdate, please see this one instead.
app-conf /opt/xen-orchestra/packages/xo-server/config.toml +0ms
app-conf /root/.config/xo-server/config.z-auto.json +3ms
app-conf /opt/xen-orchestra/packages/xo-server/.xo-server.toml +3ms
86400000
seems to be correct.
This issue only happens if we restore from backup from delta.
Stops exactly at 5mins.
Can you test with latest master?
Hi Julien Thanks. It turn out to be the same. using the latest commit https://github.com/vatesfr/xen-orchestra/commit/083db67df9e1645a2f8fe2fac564b3aecf30d55e
Are you using an HTTP proxy anywhere in your XO?
No proxy setup. Let me know if you need me to perform anything to find this issue. I see that 4 other users have similar issue on fresh installation.
Hello, my return on the command
npx app-conf xo-server . -p http.listenOptions.requestTimeout
was 0.
I altered requestTimeout
to 86400000
in /opt/xen-orchestra/packages/xo-server/config.toml
file, same result.
I tried a SMB/CIFS share and a NFS share.
No proxy on the network between the share, server and xen-orchestra
Xen Orchestra, commit ee837 xo-server 5.109.3 xo-web 5.111.1 Fully updated XCP-ng
Xen-Orchestra on Ubuntu 22.04.01
I have difficulty doing backups now after using latest commit . ee837 . Previously backups do not have socket timeout error. Now our daily Delta backups have this error as well. Restore backup is also not working. Hope this can be fixed. I have stop XOCE for now, let me know if you need help replicating the issue.
Hello, due to a Node.js issue, requestTimeout
is now set to 0
by default in XO and y ou should not change it, see a3e37ec.
Hi @julien-f the settings on requestTimeout = 0
# This breaks a number of XO use cases, for instance uploading a VDI via the
# REST API, therefore it's changed to 1 day.
#
# Completely disabled for now because it appears to be broken:
# https://github.com/nodejs/node/issues/46574
requestTimeout = 0
[http.mounts]
'/' = '../xo-web/dist'
Hi Julian,
I had to rebuild XOA from sources on a new VM for it to work.
Even after setting requestTimeout
backup to 0, restore tasks stopped at 5 minutes.
It's working now, thank you
Hey everybody,
Thanks for your reports, unfortunately, without reproducing no my side it's difficult to investigate further and to find the root cause of this issue.
If you can reproduce quickly and easily the problem, you can use git bisect
to pinpoint the problematic commit, please follow my explanation there: https://xcp-ng.org/forum/post/58981
@cirosantos0 you should try again few times. It might happen again. I have similar issue with rebuild totally okay the first time and it happens again.
okay julien will do that.
Hi @julien-f , using you explanation about git bisect; I reached this commit:
root@xen-orchestra:/opt/xen-orchestra# git bisect bad ab96c549aee17c9ae3c4e78c43962700d11cbf8d is the first bad commit commit ab96c549aee17c9ae3c4e78c43962700d11cbf8d
bisect log:
git bisect start
# good: [103b22ebb21945e347c20b1992d473b8f45590c6] fix(backups/importDeltaVm): resize cloned VDI if necessary
git bisect good 103b22ebb21945e347c20b1992d473b8f45590c6
# bad: [c8b29da67718f8d8b891a7df6474d83534d65978] feat(xo-cli): better output for returned values
git bisect bad c8b29da67718f8d8b891a7df6474d83534d65978
# good: [a73a24c1dfab189075d8ccd7b85a534d8da32b08] chore(xo-cli): don't use exec-promise
git bisect good a73a24c1dfab189075d8ccd7b85a534d8da32b08
# bad: [083db67df9e1645a2f8fe2fac564b3aecf30d55e] feat: release 5.79.1
git bisect bad 083db67df9e1645a2f8fe2fac564b3aecf30d55e
# skip: [b42127f083611435feddd63b31329fa594567ff9] feat: technical release (#6674)
git bisect skip b42127f083611435feddd63b31329fa594567ff9
# good: [bc0afb589e96694fb30410cc5843ada6a866d995] feat(lite/stories): needed components for incoming Component Stories (#6611)
git bisect good bc0afb589e96694fb30410cc5843ada6a866d995
# bad: [45b07f46f10d6df2c425423c0b81d5bf54983b77] feat(xen-api): 1.2.4
git bisect bad 45b07f46f10d6df2c425423c0b81d5bf54983b77
# bad: [4023127c8737241f0ee2f9395628eacd3bd66751] feat(xen-api/putResource): can ignore connection premature close
git bisect bad 4023127c8737241f0ee2f9395628eacd3bd66751
# bad: [ab96c549aee17c9ae3c4e78c43962700d11cbf8d] chore: use http-request-plus@1
git bisect bad ab96c549aee17c9ae3c4e78c43962700d11cbf8d
# first bad commit: [ab96c549aee17c9ae3c4e78c43962700d11cbf8d] chore: use http-request-plus@1
any possible fix on this ? I think more users are facing this issue and this is critical bug. Replication, backup and restore that takes more than 5mins.
To replicate it you can easily do this.
1.Debian 11. Fresh install minimal. 2.Follow the instructions to install from scratch.
yes i m still wathing for this fix,
https://xcp-ng.org/forum/topic/7007/a-socket-was-not-created-for-http-request-before-300000ms/36
the bus is related or is the same
I have not been able to reproduce.
If anyone can reproduce in an official XO appliance (feel free to request a trial extension if necessary) and open a support tunnel I'll be able to investigate 🙂
extend pls for my email i will try to test @.***
On 28 Feb 2023, at 21:41, Julien Fontanet @.***> wrote:
I have not been able to reproduce.
If anyone can reproduce in an official XO appliance (feel free to request a trial extension if necessary) and open a support tunnel I'll be able to investigate 🙂
— Reply to this email directly, view it on GitHub https://github.com/vatesfr/xen-orchestra/issues/6656#issuecomment-1448756730, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3ENNKZCPOYELIAZCQRTGE3WZZIGLANCNFSM6AAAAAAURG7RME. You are receiving this because you commented.
my username @gmail.com
Your trial is extended, please open a support ticket with a tunnel so Julien can access it remotely :)
ok 10 minutes pls
i m unable to open ticcket , but i whas able to reproduce the error, the backups are not working on server 2
Give this id to the support: 46431
Keep the tunnel open while @julien-f will access your XOA and work on it.
on xoa , I've used the latest branch and do not have such issues.
ok tunnel is up and running an will remain open as long as u need id,
@julien-f @olivierlambert Are u able login ? is everything good with connection to this xoa ?
@arsenieciprian Thanks, I'm able to connect, I'll investigate ASAP and I'll keep you posted :slightly_smiling_face:
any news ?
Not yet, I have a lot on my plate these days, but I'll investigate today :slightly_smiling_face:
It should be fixed, please keep me posted if that's not the case :slightly_smiling_face:
@arsenieciprian Thanks a lot for the appliance, that helped!
Xen Orchestra, commit bf51b
Tested on Fully updated XCP-NG Host and patches Fresh installation.
SR restore to Local NVME SR -> Stops at 5mins. Tried on 5 similar setup blade servers.
Tried on SR restore to NFS SR -> works okay