Error (internal): Cannot open cache file...

[skyewright]

I just noticed that graphs were not working (just get a blank).

Also if I try to use the "logging protocol" I get:

Error (internal): Cannot open cache file "/var/run/20081104180643.idx" for writing: No space left on device.

System Info suggests there is plenty of space available on the NSLU2, and things in general seem to be working okay, and the logs don't seem to report anything out of the ordinary.

Any idea what is going on?

In the meantime I'm trying a re-boot (up time was 18 days), i.e. since I updated to v2.8f.

[skyewright]

In the meantime I'm trying a re-boot

Seems okay now after re-boot...

...but it would still be nice to know what might have been happening and if there is anything I could do to prevent it happening again.

[sevenless]

Typically /var stores logs and spool data (such as for the cron daemon). Since frequent data read/write/erase on the USB stick would rapidly degrade its performance and shorten lifespan, I suspect all of this active data is stored in RAM and eventually all the old temporary files and pointers filled up the space that was allocated... thus the 'no space left on device' error.

The reboot wiped all of that volatile (but unneeded) old data and now you're probably okay for another 18 days.

Boris can probably comment a lot more on this, and maybe there is an opportunity to improve this file handling in the future and purge unnecessary old temporary files and pointers?

[skyewright]

Typically /var stores logs and spool data...suspect...stored in RAM...eventually...filled up...'no space left on device' error.

That all sounds perfectly logical. Thank you.

I'm sure I've had up times of quite a bit longer than 18 days before. Perhaps it was just some combination of things I've been doing recently...

[skyewright]

I'm sure I've had up times of quite a bit longer than 18 days before. Perhaps it was just some combination of things I've been doing recently.

It's just done it again - after less than a day's uptime.

Now re-booting...

[admin]

"/var/run/*.idx" files are used for some house-keeping when using the http data-logger function. Meteohub cleras them from time to time, but may be not often enough, when there are very many calls to http data-logger.

This is the crontab line:
17 */6 * * * rm /var/run/*.idx

Just change it to every hour instead of every 6 hours, when WD is firing http-requests every couple of seconds as mad ;-)

[skyewright]

"/var/run/*.idx" files are used for some house-keeping when using the http data-logger function. Meteohub cleras them from time to time, but may be not often enough, when there are very many calls to http data-logger.

As it does...
i.e. 'latest reading' every 5 seconds, then 'all the last minute' every minute - to catch the ones inevitably missed by the "'latest reading' every 5 seconds" approach (but ignoring rain, because that can result in duplication). :S
Sometime I may try to suggest a slight change in the regime...

What I think seems to have tipped the balance on the occasions when this has happened has been an unusually large number of manually invoked graph requests in the previous few hours. And it seems to have happened at around the same time, between 1700 and 1800.
Would that make sense?

This is the crontab line:
17 */6 * * * rm /var/run/*.idx

Thanks.
Useful to know, especially as during my Fit-PC experiments I can have 2 PCs runing WD and using the logging protocol.
Presumably I need to SSH to change the crontab?
I hope this isn't a daft question, but where do I find the cron file on Meteohub?
I'm sure it's time I learnt how to edit that... :)

[admin]

cron comes with a special editor. just say "crontab -e" and you are there.

If you might want make a copy of it before editing, you do find the file at "/var/cron/tabs/root"

[skyewright]

admin wrote:
If you might want make a copy of it before editing, you do find the file at "/var/cron/tabs/root"/quote]
Of course.

Ah. "ed". Mmmm. I think I used to use the old MSDOS equivalnet, but that was a long time ago! I think that as well as making a copy I'll pratice first with comething less critical. ;)

If I see the problem occur in the mean time at least I now know I can work around by SSH and manually rm /var/run/*.idx :)

Thank you.

[skyewright]

Sometime I may try to suggest a slight change in the regime...

I've made a Feature Suggestion on Weather-Watch asking if the "lastest reading every 5 seconds" could be made optional, since the "all the last minute" sees everything anyway (provided that it knows not to ignore rainfall...).

[skyewright]

Ah. "ed". Mmmm. I think I used to use the old MSDOS equivalent, but that was a long time ago!

I now realise that that should have been Ah, "vi"!
No wonder I was getting no where trying to treat use "ed" syntax - it's a long time since I'd used ed, but I'd never used vi so I didn't recognise it! The first google hit I found on crontab had suggested that ed was usually the default editor. Seeing messages like "q not supported" made be a bit suspicious, but in my ignorance I thought in maybe it was a very cut down version! :laugh:

While googling I found that the choice of editor was user modifiable, and that I should be able to change it via the EDITOR environment variable. When I did

set | grep EDITOR

to check that, I discovered that it was already set to vi! :laugh:

A quick trip to a vi tutorial and the crontab is now updated to rm /var/run/*.idx every hour (I think)

Code: Select all

17 */1 * * * rm /var/run/*.idx

Looking back on this I suspect that the problem has actually been cropping up several times a day for ages. Now I know to look for the cache seems to have been filling in a little over 5 hours by requests from WD, then being cleared automatically within an hour. What I think brought it to light was trying (and failing) to manually run a graph at a point when the cache was full, then I happened to try a logging protocol "last reading" call just to see if that was working, an that's when I saw the message that is the topic title!

Oh well, we live and learn - if we are fortunate. :)

I know know a bit more about Linux systems than I did before. :cheer:

Thanks for the pointer.