Persistence service throws tons of errors

There are tons of errors like this within the openhab.log:
2022-10-02 07:35:00.700 [ERROR] [d4j.internal.RRD4jPersistenceService] - Could not create rrd4j database file ‘/var/lib/openhab/persistence/rrd4j/G_A2_FOG.rrd’: Invalid file header. File [/var/lib/openhab/persistence/rrd4j/G_A2_FOG.rrd] is not a RRD4J RRD file

And based on a tail -f on the log file, it keeps raising those errors frequently - probably caused by every run of the script behind the continuous timer. The specific item (G_A1_FOG) is not used in any way - it’s just for future and currently only referenced by an HabPanel Switch widget. There is no connection to any channel of an KNX Device. However, it’s also never initialized an always have a NULL state.

Does this make sense to anyone?

So, why do you keep this item at all. The fact that it isn’t linked to a channel has no effect on the persistence service.
Looking for that unused item via MainUi would show the analysing graph, which in turn is request data from the persistence service.

By default, RRD4j is persisting all items. You have the option to custom the persistence strategy to persist only some of your items (and probably not G_A1_FOG).

So, if we gather up the jigsaw pieces;

rrd4j will by default, persist ‘everything’ (really, all Item types that it can)

A valid, if very unusual, usage of an Item used for routing commands only.

As I understand it, rrd4j creates a file/table for each Item as it is first used.
Persistence service does not persist NULL (or UNDEF) states, so it sounds like that step will never be carried out.

So, if the Item is supposed to be persisting (by default) then other parts of o[penHAB may look for the persisted data - and fall in the hole of there being no file/table in existence.

An off the wall approach would be to change this Item type to say, a String type. rrd4j persistence then isn’t interested in it, nor is the UI analyzer etc.

Another way would be to set your Item state to non-NULL for five minutes - then change it back if you like. Long enough to create a table that may never record anything else.

1 Like

Thanks for all your takes on the issue.

First, G_A1_FOG is unused for now but in a very near future it will become used. But I should make it a switch, what it finally becomes and initialize it to OFF.

@Rossko57: if I understand you correctly, that may fix the issue since a table would be created but never updated as long as this item stays OFF, right? I’ll try that out.

Cheers, Christian.

Not quite. A table should be created if the Item’s state is non-NULL. Thereafter, state will be peridically persisted by default, unless state is now NULL (or UNDEF). That includes OFF, which is of course a valid state (for a Switch type Item).

Note that defaults for rrd4j also includes restore-on-startup. The last persisted state will be restored at openHAB boot time, that’s going to be OFF in this case, even if that was months ago.

Taken together - update your Item to OFF just once, by developer sidebar say, and all your trouble goes away forever, with NULL not to be seen again.

That might not be quite what you want - it’s a lie, your yet-to-exist switch is not really off, it is indeterminate.
You could set the Item to UNDEF state if you wanted to indicate (in rules or UI) it is not available yet.
The trouble is the (repaired) restore-on-startup will fight you and set OFF or whatever at each reboot, so if you want to do that you need to do it in a startup rule every time.

Unless you go to the trouble of abandoning default persistence configuration altogether and configuring a manual selection (which is not such a bad idea in any non-trivial openHAB installation).

1 Like

It seems that error arrived for ANY item the system wants to persist - also for such who indeed has valid states… so I’m a little puzzled because otherwise the system runs fine and the erroe itself doesn’t say much about probable causes.

Maybe you have a permission problem on the folder containing the RRD4j folder.

1 Like

Yep - that how it looks - but it’s openhabian from the most recent Image but I’ll make sure. Even though I think the error message would be more clear in this case.

Errors for all items?
Do you see anywhere any persistec data at all? ( Like on MainUI when checking an item or on charts or directly in the db via the RESRÜT API)?
If you don’t have persisted data yet, stopping openHAB, deleting all .rrd files and restarting openHAB again would be MY next try.

Hi! Are you running on a raspberry pi?
I also periodically get this problem, it’s caused by zram volume getting full. I remember i complained about it, but the response was basically “rpi is a toy, use a real server”.
It should be possible to connect an external HDD and use it, but:

  1. you can’t configure a data folder for RRD4j, it’s hardcoded
  2. It should be possible to mount on top of the existing dir, but i don’t know how to disable this zram thing.

Yes I’m running a PI… however, if we talk about persisting the actual value of an Item, zram shouldn’t get filled up by around 100 Items, or so?

Remember it writes a full history, not just the last value.
Many variables factor in, the volume can “officially” be even not 100% full, but remember your RAM is in fact shared, so other volumes (like log) can also contribute. This is especially nasty because an error on RRD volume effectively causes the log to blow up, filling log volume (which is also zram), thus aggravating the problem

Just discovered Could not create rrd4j database file error in OH3 - #54 by mstormi . How old is your install?
It’s easy to distinguish zram blowup vs something else. Try creating an empty file on the volume. If you can’t, and get a “readonly fs” error, this is RAM shortage. If not, it’s something else

It’s a most recent installation, maybe two weeks ago from the openhabian image. Since the system is not connected to the public internet, it’s not easy to make an upgrade.

Is there a possibility to switch-off persistency for the entire installation? It’s just a waste of computation time and wears down the SD-Card. I have no need for any kind of persistency - the majority of the items are maintained by the KNX system and the few others are updated constantly y rules. Having said that I assume, that any item is also held in memory by the actual instance running!

deinstall/remove all persistence services.

Thank you, Wolfgang - I just did and, oh wonder, the errors are gone:-)

1 Like