gadi went down last night and killed existing persistent sessions.
I (re)started one with a different name from previous, logged out of gadi, logged back in, ssh’d to the new persistent session, and ran rose-suite clean just to be certain everything was pulled through.
rose-suite run then failed with:
[FAIL] cylc run u-by395-ram3_flagship # return-code=1, stderr=
[FAIL]
[FAIL] ERROR: No hosts currently compatible with this global configuration:
[FAIL] suite servers -> run hosts:
[FAIL] ['gadi-persistent-session.bw6466.fy29.ps.gadi.nci.org.au']
[FAIL] suite servers -> run host select -> rank:
[FAIL] random
[FAIL] suite servers -> run host select -> thresholds:
[FAIL] None
My old persistent session name was gadi-persistent-session
My new one was fy29-persistent-session
I can’t for the life of me figure out where the suite or cylc is storing the information about the old persistent session name. It doesn’t seem to be in the suite’s rose directory - grepping it for gadi-persistent-session returns nothing.
.config/gadi-login.conf only contains my default project.
My .persistent-sessions/cylc-session contains the new persistent session name.
For now I’ve taken the path of least resistance and created another persistent session with the old persistent session name so that I can run the suite, but it would be good to know what I am missing for a new session name to be picked up by cylc.
I’m not completely sure where your error comes from, but one possible reason is that you changed the content of .persistent-sessions/cylc-session with the new persistent-session name only after having already loaded the cylc module.
Cylc gets its linked persistent-session at load-time from the .persistent-sessions/cylc-session file.
In that case, you can try unloading and re-loading the cylc module and it should work (at load-time it should tell you which persistent-session it is connected to).
Also, just out of curiosity, was there a specific reason why you renamed your persistent-session?
one possible reason is that you changed the content of .persistent-sessions/cylc-session with the new persistent-session name only after having already loaded the cylc module.
I don’t think it’s this - my order of operation was I created the new session, ssh’d into it and then did my standard suite setup, which includes loading cylc.
Also, just out of curiosity, was there a specific reason why you renamed your persistent-session?
Yes - mistake! But also to align with the naming of compute project-based persistent-sessions, as I have a few rather than just the one so it’s easier to have them named by project.
It’s not a biggie for now, I have the suite running under the old session name. I’ll come back to it after the long weekend and see if it’s still persisting, and we can dig further if necessary.
Not sure if this will help your case, but playing around with this I found out something I didn’t know (double-checked the cylc modulefile source code):
The persistent session used by Cylc at runtime is the value of the CYLC_SESSION env variable.
At module load-time, Cylc reads the CYLC_SESSION env variable first.
If the env variable is empty or not set, it reads the ~/.persistent-session/cylc-session file and assigns the content of its last line to the CYLC_SESSION variable
If the env variable is non-empty, it stores its value into the ~/.persistent-session/cylc-session file
This means that the ~/.persistent-session/cylc-session can be changed by setting the CYLC_SESSION variable (which is the main source of information at runtime) and then loading the cylc module.
But also to align with the naming of compute project-based persistent-sessions, as I have a few rather than just the one so it’s easier to have them named by project.