Hello, I installed CPU Temp plugin and all works fine on dashboard:
But grap is not updated:
and this is sudo omv-salt deploy run collectd rrdcached
some guideance to solve?.
PD. uninstall and re-install of the plugin do not solve it:
Hello, I installed CPU Temp plugin and all works fine on dashboard:
But grap is not updated:
and this is sudo omv-salt deploy run collectd rrdcached
some guideance to solve?.
PD. uninstall and re-install of the plugin do not solve it:
and this is sudo omv-salt deploy run collectd rrdcached
It is creating the cputemp config. I think you just need to wait a little longer.
PD. uninstall and re-install of the plugin do not solve it:
Nope and I really don't recommend doing that. That is the windows way of fixing things.
wait is not sollution:
try the check rrd database entry in omv-firstaid then.
Not sure then. I don't use monitoring and it is working on my dev system. Someone else will have to look into this.
it's possible to uninstall cputemp pluging and delete all files related, son can be generated fresh next time?.
I suspect that some config files are bad , but not sure what is the exact file.
son can be generated fresh next time?.
saltstack writes them fresh every time it runs unless they don't need to be changed. Hence why it doesn't help to uninstall the plugin.
I suspect that some config files are bad , but not sure what is the exact file.
Why do you assume that? I said it is working on my system with the same plugin. If it was broken config created by the plugin, it would be broken on all systems.
I suspect that some config files are bad , but not sure what is the exact file.
What other plugins do you have installed? Do you have writecache installed? I'm wondering if it has anything to do with what was reported here.
I also stopped seeing CPU graphs on my dashboard recently. Completely removing the writecache plugin appears to have solved it.
Do you have writecache installed? I'm wondering if it has anything to do with what was reported here.
I also stopped seeing CPU graphs on my dashboard recently. Completely removing the writecache plugin appears to have solved it.
Of course, writecache gets blamed for everything. It doesn't matter that I have always recommended disabling monitoring (install script disables it) when using flashmemory or writecache. You could just remove the rrd directories from the list but rrdcache is probably the heaviest writes which is why I recommend not enabling monitoring on systems that need writecache. That said, I have writecache installed on my system with working graphs just so I can test what people are going to do anyway.
Of course, writecache gets blamed for everything.
I merely relayed my experience to the OP:
I didn’t have any time to debug any further than that nor report it. I am merely letting OP know that that might be a cause / potential fix for them.
I merely relayed my experience to the OP:
I get it but the solution is just avoiding the problem and nothing ever gets fixed.
I didn’t have any time to debug any further than that nor report it
People just expect me to spend the time. I can't recreate this. If people don't help, things don't get fixed.
I am merely letting OP know that that might be a cause / potential fix for them.
And when people uninstall writecache, their OS drives are going to start failing from excessive writes. That is a support nightmare but not your problem.
raulfg3 try adding the following to the Services box in the writecache plugin:
With all due respect, one of the big reasons I have very little motivation to report issues is the attitude and responses you have to them when they are made. I have personally experienced it on the forums before, and I have observed it in your responses to others.
You only have to look at your response here in this thread. You immediately make the exchange more combative than it needs to be, with talk about "blaming" writecache; when all I did was try to help OP by simply letting them know what I had observed on my system. I have no idea whether it is even writecache, or indeed if the OP even has writecache installed.
Whilst I have massive respect for the work you have done and continue to do, I'm afraid to say that you come across to me as quite bitter and angry with users when issues are reported to you, and appear to take bug reports with your plugins too personally. And that makes issue reporting quite an unpleasant experience, and so far less likely for me to take the time to do it. I don't want to get involved in a back-and-fourth every time I try and report an issue I've observed.
With all due respect, one of the big reasons I have very little motivation to report issues is the attitude and responses you have to them when they are made. I have personally experienced it on the forums before, and I have observed it in your responses to others.
You only have to look at your response here in this thread. You immediately make the exchange more combative than it needs to be, with talk about "blaming" writecache; when all I did was try to help OP by simply letting them know what I had observed on my system. I have no idea whether it is even writecache, or indeed if the OP even has writecache installed.
Whilst I have massive respect for the work you have done and continue to do, I'm afraid to say that you come across to me as quite bitter and angry with users when issues are reported to you, and appear to take bug reports with your plugins too personally. And that makes issue reporting quite an unpleasant experience, and so far less likely for me to take the time to do it. I don't want to get involved in a back-and-fourth every time I try and report an issue I've observed.
I am bitter. What do you expect after 15 years working with people expecting me to do all of the work (not saying you are). I didn't start this way. It is very hard to stay in open source.
And I try not to be an asshole right away but when I asked for more output because I can't reproduce, people want me to tell them exactly what to do on a system I can't see and do all of the work. I have spent more time than ever trying to make the omv8 plugins better and people criticize/complain more than ever and have no patience and downright rude sometimes. You spend hundreds of your free time hours and have someone say bad, non-constructive things about your work and see if you take it personally. I don't take bug reports personally if they are a bug. But when people say something is a bug without taking any time to figure out how a plugin works over and over and over, it is irritating.
I'm sorry I make things so unpleasant for you but try to spend a second in my shoes and have a little patience with me. It will usually soften things. No one is helping me. I am helping others and get nothing out of it. How unpleasant do you think I really am??
sorry no writecache plugin installed on my side.
I do not think in a bug on cpu pluging, probably something bad in my side, because of this i only need to know what files are created or involved in the creation of rrdgraph, so i can delete the cpu plugin and delete this persistant files so next time i reinstall cpu plugin, it works fine like in other simmilar machines.
I’d like to take this opportunity to acknowledge that you do a good job, and that it is often us users who tinker with things we shouldn't.
I’m sorry that this thread ended up ruining your day.
what files are created or involved in the creation of rrdgraph
If you aren't worried about the cputemp history, try (as root:
I have similar problems since the last update I ran. The graphs in "Performance Statistics" are all visable on the UI but there is no data in it. Rebooting worked partially.
The drop in data seems to start at the time the daily flush is active in my settings on all the 3 occasions.
In Logs->Messages there is a lot of these messages
monit[822]: 'rrdcached' start: '/bin/systemctl start rrdcached'
monit[822]: 'rrdcached' trying to restart
Fiddling with Gemini told me the following:
QuoteRoot Cause: omv-mkrrdgraph was throwing ERROR: Unable to connect to rrdcached: Connection refused. The UNIX socket (/run/rrdcached.sock) had broken permissions or failed to initialize properly after the system update, causing collectd and monit to fail communicating with rrdcached.
and permisssions seems to be wrong according to Gemini.
Quoteroot@nas-julian:~# ls -ld /var/lib/rrdcached/
drwxr-xr-x 1 root root 4096 Sep 9 03:45 /var/lib/rrdcached/
The drop in data seems to start at the time the daily flush is active in my settings on all the 3 occasions.
Try adding to the writecache services field.
I restarted the NAS to make sure data is coming in for CPU etc., then I added the parameters to Write Cache settings and performed the flush via UI. Data is coming in afterwards and rrdcached is still running. That might be the solution. Thanks!
(Gemini had the same idea after I fed it the last two meaningful changes on the writecache script. You were faster and I trust people with knowledge more then AI and me prompting without too much knowledge. Shxt in, shxt out.)
ata is coming in afterwards and rrdcached is still running. That might be the solution.
Thanks for testing.
Don’t have an account yet? Register yourself now and be a part of our community!