Write state.json to temporary storage
hmoffatt opened this issue · comments
Can I suggest writing states.json to temporary storage, instead of to the current directory which will usually be on the SD card? There's no need to write that to SD card every time and wear out the card.
/run is on tmpfs (in-RAM storage), although the pi user won't have write access to it by default so that would need to be set up on boot for the states file. The pi user can write to /run/user/1001, but root won't know where to find that.
First of all, I wanted to thank you for giving so much valuable feedback on this project. It is humbling to me that anyone one take the time to dive in a help make my little project better. So a big hearty thank you!
OK, so, this is a really, really cool idea. I have been concerned to some degree with flash wear-out, but wasn't sure how to tackle this. I feel like this is a great option, but I also will need to do some research on this to understand the limitations and how I can use this. Give me some time, but I will definitely look into implementing this one.
Thanks!
Thinking about this some more, I think you could just run the control and web interfaces in one program and avoid writing the state to the file system at all.
If the pi user is added to the gpio group, they can access the GPIOs (no need to be root, as long as you're not trying to run it on port 80). This is a good idea anyway rather than running it as root.
Then if you ran the control loop as a separate thread from the wsgi app, they can just share the state in memory and never write it to the file system.
Definitely a good idea, and what I wanted to do from the beginning. However, I just couldn't get threading to work with Gunicorn. Was starting to look at Gevent to see if there was a "proper" way to have a background thread while using Gunicorn. Still haven't gotten that to work. Seems like Gevent threads are blocking. Any help here would be greatly appreciated.
Alternatively you could actually create the control thread and also the gunicorn application directly from python, rather than expecting the web app to be launched from gunicorn at the command line. What I mean is: http://docs.gunicorn.org/en/stable/custom.html. Then the thread is completely separate to the gunicorn instance?
It seemed to work OK when I started the control loop on a thread before the Flask app was created, but if gunicorn was ever set up for >1 worker than it would create the app (and the background thread) for each worker, which wouldn't be good.
So I used the custom gunicorn app approach and this is working. It starts the control thread, then starts gunicorn. I haven't removed the reading/writing of the state/config to file all the time yet though so it's not ready to merge. It's pretty simple though: hmoffatt@c1a428e
Excellent! This is super interesting to me because it would simplify a couple of other projects that I have currently as well. As soon as you get it all merged, let me know. I'm eager to check it out so I can update this project and others!