Some files in /home/dev/secured are corrupted on shutdown


I am developing a project that counts, in seconds, how long signals is active. My approach requires a JSON file to be read and written to every 1 second. So this file is pretty much always in use. During system testing, I noticed that whenever I power down the groov EPIC and turn it back on, that file gets corrupted. It is a JSON file that contains 4 key value pairs:

“timestamp”: 1699898856527,
“sig_1”: 291034,
“sig_2”: 287280,
“sig_3”: 285840

When the EPIC powers back on, this is what the file turns into:

The file is located in /home/dev/secured/seconds.json

At first, I assumed it was the Node-RED read / write nodes that are improperly closing the file or something. So I decided to make two backups of that file, and to alternate writing to each backup file once every 10 seconds. If the ‘original’ file was corrupted, I would compare timestamps between the two backup files and grab the latest one. to My assumption was that 20 seconds would be more than plenty to ensure that at least one backup file is closed. That did not work as all three files are corrupted when the device restarts.

I decided to ditch the Node-RED read / write nodes and to use the exec node to read and write. I used cat to read in a file, then echo to write it back. That still didn’t resolve the issue, even when using the two backup files method mentioned above.

There are other files in /home/dev/secured/ that remain intact on restart. Of course, I am assuming the problem is that the file is not closing. Really, I am unsure what the cause of this problem is. Any insight would be appreciated!

Hi Karim. Welcome to the forums.

What firmware version are you on? (groov Manage, Info & Help → About).

Hi Beno,

Thanks for replying.

Under groovEpic it says Minimum Firmware Version 3.0.0
Under I/O Coprocessor, it says firmware R1.0i

I need to know this one here:

The min version is just letting you know that you cant load anything lower than that version.
Its not telling you the current running version.

Oh thank you for clarifying. The System Version is 3.4.4-b.128

I updated to the latest firmware and the problem is persisting. I also tried this on another PR1 and it did not resolve the issue. Here is a minimum reproducible example:

[{"id":"dc2d9bf23fbc03cf","type":"inject","z":"a36e73017ccd75a7","name":"","props":[{"p":"filename","v":"/home/dev/secured/seconds.json","vt":"str"}],"repeat":"1","crontab":"","once":true,"onceDelay":"10","topic":"","x":175,"y":160,"wires":[["02115b3127b3a289"]],"l":false},{"id":"7f73059d930d109c","type":"file","z":"a36e73017ccd75a7","name":"Write_File","filename":"filename","filenameType":"msg","appendNewline":false,"createDir":true,"overwriteFile":"true","encoding":"none","x":325,"y":160,"wires":[[]],"l":false},{"id":"02115b3127b3a289","type":"file in","z":"a36e73017ccd75a7","name":"Read_File","filename":"filename","filenameType":"msg","format":"utf8","chunk":false,"sendError":false,"encoding":"none","allProps":true,"x":225,"y":160,"wires":[["9e788daef519c2aa"]],"l":false},{"id":"9e788daef519c2aa","type":"function","z":"a36e73017ccd75a7","name":"function 17","func":"var times = JSON.parse(msg.payload)\ntimes.counter += 1;\nmsg.payload = times;\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":275,"y":160,"wires":[["7f73059d930d109c"]],"l":false}]

Thanks for boiling this down.

Could you please email this example (and perhaps a link to this thread) to our support group so they assign an engineer to dig into this.

I reached out to the support team and it seems this a firmware bug. I was told that they will look into this. We discovered that this only occurs when the restart process is not graceful, i.e.: flipping the rocker switch or losing power. The files do not corrupt when the device is restarted from groov Manage. This also happens on the RIO.

Thank you,

It may or may not be related to your problem… I had this problem running a program in shell access. This was easily replicable on my end by creating the file and cycling power.

It might be an issue with how the Linux OS is caching and it not being immediately saved to permanent storage. On my shell access program, I was able to resolve this by sending a Linux “sync” command. Not sure how that could be tested with Node-Red.