You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
leap-second auto-update cache warning in 4.0.1 #10523
I'm attempting to update our production environment to use a newer version of astropy and in integration testing my application I get:
WARNING: leap-second auto-update failed due to the following exception: RuntimeError('Cache is locked after 5.01 s. This may indicate an astropy bug or that kill -9 was used. If you want to unlock the cache remove the directory /home/jeanconn/.astropy/cache/download/py3/lock. Lock claims to be held by process 43777.',) [astropy.time.core]
I first saw the issue with astropy 4.0.1.post1 but still see the warning with the dev version installed via pip per your bug report directions.
From a search in open issues I suppose this may be related to #9970
Expected behavior
I expected no change in outputs.
Actual behavior
I received a warning message.
I was not expecting a leap-second or astropy cache related warning. I note there are no leap seconds in the range of my test or planned for the future.
Steps to Reproduce
This would take more digging as I'm not sure which piece of the code made the call to astropy that threw out this warning.
changed the title [-]leap-second auto-update cache warning when attempting to update env to new(er) astropy[/-][+]leap-second auto-update cache warning in 4.0.1[/+]on Jul 1, 2020
This would be fixed by #10437 because that PR completely removes the lock. If you feel like it, you could install from that PR branch and see if the problem really goes away for your use case. Thanks for reporting this!
Activity
[-]leap-second auto-update cache warning when attempting to update env to new(er) astropy[/-][+]leap-second auto-update cache warning in 4.0.1[/+]pllim commentedon Jul 1, 2020
This would be fixed by #10437 because that PR completely removes the lock. If you feel like it, you could install from that PR branch and see if the problem really goes away for your use case. Thanks for reporting this!