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

python::meta fallback seemingly fails #1287

Closed
adriansev opened this issue Sep 17, 2020 · 7 comments
Closed

python::meta fallback seemingly fails #1287

adriansev opened this issue Sep 17, 2020 · 7 comments

Comments

@adriansev
Copy link
Contributor

Hi! I see in v4.12.4 that fallback still seems not working ..
see all the relevant logs in https://cernbox.cern.ch/index.php/s/Guj3ZyThWEMScn7
@simonmichal Any idea what was forgotten/missed?
Thanks a lot!!
Adrian

@adriansev
Copy link
Contributor Author

adriansev commented Sep 17, 2020

splitting the meta in the 2 sources i get:

xrdcp -P -f -v 5fd2de06-922f-5940-8f67-8758ca2ff001_upb.meta4 test.zip
[0B/0B][100%][==================================================][0B/s]
Run: [ERROR] Server responded with an error: [3014] Unable to open file  /eos/aliceupb/grid/00/05156/d1e6d2e4-f7d8-11ea-9aeb-9b81bcf0d084; Network is unreachable (source)

xrdcp -P -f -v 5fd2de06-922f-5940-8f67-8758ca2ff001_cern.meta4 test.zip
[366.7MB/366.7MB][100%][==================================================][5.392MB/s]

so the problem is the error that eos throw and that disable the copy procedure of the client ... which is absolutely bad and awful, i really hope that i do not have to re-create in my tool a copy-manager in order to bypass such happenings...
amazingly enough, upb is the same site that started the discussion about fallback previous time.
LE. there were 2 FSTs off because of power problems, so there was no ambiguous software state.

@simonmichal
Copy link
Contributor

@adriansev : this must be a regression, by policy ENETUNREACH or kXR_noserver should be retried at metalink level, I just pushed a fix f0c3466

@adriansev
Copy link
Contributor Author

@simonmichal great! thanks a lot!! will this be also backported to 4.x branch? there will be quite some time until everyone will switch to 5.x and of course the clients will be the last to do so ... thanks a lot again!

@simonmichal
Copy link
Contributor

@adriansev : well, if there's strong desire we can have another bugfix release for 4.12.x series, though I strongly encourage you to move to xrootd 5 ;-) I'm looking into the issues you reported and of course I will try to make the transition as smooth as possible ;-)

@adriansev
Copy link
Contributor Author

@simonmichal yes, please backport to 4.12.x as ALICE is not prepared to move to 5.x (AFAIK there are problems with both ROOT 5 and 6, where ROOT 5 still being the main version). Thanks a lot!

@simonmichal
Copy link
Contributor

@adriansev : the patch is backported to stable-4.12.x, can we close this one?

@adriansev
Copy link
Contributor Author

yes, thanks a lot!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants