Hi,
I’m trying to run a script which reads certain set of values from a file. Uses these values to simulate a nengo network. Updates them at the end of the simulation and writes them back to the file. I ran it successfully a bunch of times, this error/warning didn’t appear until some point later.
It shows a warning, "~/site-packages/nengo/cache.py:497: UserWarning: Decoder cache could not acquire lock and was set to readonly mode."
And it does not seem to write the updated values back to the file.
I’ve run this script a bunch of times already and it didn’t show any errors/warnings earlier and it was updating the values just fine.
Has anyone come across this error and found a way around?
The cache warning is not the cause of your file not updating, but the two are definitely connected in some way. I have two guesses:
Are you running multiple copies of Nengo or Python at once? It might be the case that an old version has acquired the lock for the cache, and has opened the file that you’re updating, which is preventing other copies of Nengo or Python from updating those files correctly. Open up a task manager (in Mac OS X: Activity Manager; in Linux: ps -aux or a graphical one like xfce4-taskmanager) and see if you have a copy of Nengo or Python that you’re not expecting to be there.
Have you run out of disk space on your hard drive? I’m not 100% sure, but it seems like you could get the symptoms you’re describing if your disk is full. Try freeing up some space, or store your file on an external device. Note that Nengo will create a decoder cache that, by default, takes up 512 MB. If that’s space you can’t spare, you can reduce it through making a nengorc file.
If you are sure, that you are only running a single instance of Nengo and you are still getting that warning, try to delete the file ~/.cache/nengo/decoders/index.lock.
It would be helpful, if you could provide us with some more information on your environment:
I’m running it on a server running centos 6.8 since I have to run multiple instances of the same network. I’m running it using multiprocessing. Perhaps I aborted one instance at some point when a process had acquired a lock and didn’t yet release it yet. Deleting index.lock as suggested by @jgosmann worked. It’s solved now.
Just as additional information for someone encountering this in the future,
I was running it on Centos 6.8 on a cluster using multiprocessing.
Python version 2.7
Nengo 2.4
Probably, the lock will be released when interrupting the process with Ctrl+C (which sends a SIGINT signal). But the kill command sends SIGTERM by default. I will look into the possibilities of catching that signal and releasing the lock to make this more robust.