CactiEZ (CENTOS)
Cacti 0.8.6h
Perl 5.8.5
Script asspstats.pl
Script results may take several seconds to return. Log file indicates :U result in 7 seconds even after I change the timeout value to 70 seconds and increase the threads to 2.
Am I missing another setting or need to change something else?
Thanks for any help or ideas.
Script and Script Server Timeout Value - getting :U
Moderators: Moderators, Developers
- TheWitness
- Developer
- Posts: 14834
- Joined: Tue May 14, 2002 5:08 pm
- Location: MI, USA
- Contact:
Please try the new Cactid in the Announcements forum. Otherwise, it will be released quite soon.
TheWitness
TheWitness
True understanding begins only when we realize how little we truly understand...
Life is an adventure, let yours begin with Cacti!
Author of MacTrack, Boost, CLog, SpikeKill, Platform RTM, DSStats, maintainer of Spine, lot's of unpublished work and most of Cacti's bugs.
_________________
Official Cacti Documentation
GitHub Repository with Supported Plugins
Central Plugin Repository
Central Templates Repository
I'm still out there people. Getting excited for Cacti 1.2. I think it will be a great release.
Life is an adventure, let yours begin with Cacti!
Author of MacTrack, Boost, CLog, SpikeKill, Platform RTM, DSStats, maintainer of Spine, lot's of unpublished work and most of Cacti's bugs.
_________________
Official Cacti Documentation
GitHub Repository with Supported Plugins
Central Plugin Repository
Central Templates Repository
I'm still out there people. Getting excited for Cacti 1.2. I think it will be a great release.
- gandalf
- Developer
- Posts: 22375
- Joined: Thu Dec 02, 2004 2:46 am
- Location: Muenster, Germany
- Contact:
Re: Script and Script Server Timeout Value - getting :U
Personally, I'd try to get a workaround. At least (AFAIK), one cactid thread would wait that long for the results to come up and so be blocked out of other work. Possible workaround would be, to create the data on the target system e.g. by means of a cronjob putting th eresults into some dataset (e.g. html, that you may fetch via wget from cacti). Yep, this is _not_ a great idea, especially when it comes to deployment of crontabs ...issmsatch wrote:CactiEZ (CENTOS)
Cacti 0.8.6h
Perl 5.8.5
Script asspstats.pl
Script results may take several seconds to return. Log file indicates :U result in 7 seconds even after I change the timeout value to 70 seconds and increase the threads to 2.
Am I missing another setting or need to change something else?
Thanks for any help or ideas.
Reinhard
It's working now!
Thanks for everyone's help.
I upgraded cactid but didn't make a difference, also upgraded to 0.8.6i (like the enhancements to view the log!)
Strangely enough, I modified the script as posted in another topic. The last line in the script was:
print "smtpcon:$smtpcon totmess:$totmess bayspam:$bayspam locmail:$locmail whitemail:$whitemail\n\n";
changed to:
print "smtpcon:$smtpcon totmess:$totmess bayspam:$bayspam locmail:$locmail whitemail:$whitemail";
now the rra file is updating again.
Kinda wierd it worked then stopped and taking the new lines out fixed it?
The only things that I think could have affected the system is that yum updates are enabled and also have a little trouble with logrotate which is apparently due to /tmp being noexec so will fix that.
(I can see some folks are going to want instructions upgrading that are running the CactiEZ distro..or they'll have to wait for yum updates )
Anyway, thanks again for the help and thanks for a great product!
Thanks for everyone's help.
I upgraded cactid but didn't make a difference, also upgraded to 0.8.6i (like the enhancements to view the log!)
Strangely enough, I modified the script as posted in another topic. The last line in the script was:
print "smtpcon:$smtpcon totmess:$totmess bayspam:$bayspam locmail:$locmail whitemail:$whitemail\n\n";
changed to:
print "smtpcon:$smtpcon totmess:$totmess bayspam:$bayspam locmail:$locmail whitemail:$whitemail";
now the rra file is updating again.
Kinda wierd it worked then stopped and taking the new lines out fixed it?
The only things that I think could have affected the system is that yum updates are enabled and also have a little trouble with logrotate which is apparently due to /tmp being noexec so will fix that.
(I can see some folks are going to want instructions upgrading that are running the CactiEZ distro..or they'll have to wait for yum updates )
Anyway, thanks again for the help and thanks for a great product!
Let me know what needs doing, and I will get it into the next release of CactiEZ. I may know my way around Linux, but just like everyone else, I'm still learning tooissmsatch wrote:I can see some folks are going to want instructions upgrading that are running the CactiEZ distro..or they'll have to wait for yum updates

I pulled out my notes so hope this helps. I think this what you want?Let me know what needs doing, and I will get it into the next release of CactiEZ. I may know my way around Linux, but just like everyone else, I'm still learning too
Chapter 4. Upgrading Cacti
Knowing the path where cacti is normally installed versus on the CactiEZ distro and also how to preserve the plugins and scripts would help.
Step 1. No change.
Step 2.
shell> mv cacti cacti_old
Usually Cacti resides in /var/www/html/cacti
CactiEZ uses /var/www/html
so CactiEZ instructions would read mv /var/www/html /var/www/html_old
Step 3.
Need full path instructions where to untar the new version or a suggestion where to put it. I'm not sure so it would be nice to know where I put it or get into the habit of putting code in the same place.
/usr/src or /usr/local/src ?
Step 4.
.....where to mv the new version.
(/var/www/html)
Step 5.
Edit /var/www/html/include/config.php
unless they changed the database password, it will be this:
$database_password = CactiMadeEZ
I'm not certain how to preserve the plugins but I think you need to copy the old plugins /var/www/html_old/include into /var/www/html/include and edit the config.php file. Look at the orignal config.php file for the plugins.
Steps 6,7 & 8
replace cacti/ with html/
Step 9
shell> chown -R apache rra/ log/
not
shell> chown -R cactiuser rra/ log/
That should be good for a start. Might include steps on how to fall back to a previous version.
Hope this helps.
Seems I qouted the wrong text. This is what I was actually wondering about.issmsatch wrote:I pulled out my notes so hope this helps. I think this what you want?Let me know what needs doing, and I will get it into the next release of CactiEZ. I may know my way around Linux, but just like everyone else, I'm still learning too
issmsatch wrote:also have a little trouble with logrotate which is apparently due to /tmp being noexec so will fix that
The original CactiEZ install worked great. But yum update has introduced some issues.
logrotate-3.7.1-6.RHEL4.i386.rpm should fix the logrotate problem. A yum updated logrotate was using /tmp for the temporary scripts. This directory shouldn't have executable permisions for security reasons. My understanding is that the postrotate scripts weren't restarting syslogd. You'd see ALERT messages in /var/log/messages if you were experiencing this problem.
...and unfortunately three boxes were still locking up after doing an rpm update of logrotate. It was hard to catch but looks like the culprit is the 2.6.9-42.0.3.EL kernel. The only clues I'd see in the logs is that syslogd was restarted. A video monitor attached to one box is blank. I loaded CactiEZ onto a laptop, gave it an IP address and let it sit for a few days without making any changes. It locked up last night and had a "Kernel panic - not syncing: Fatal exception" on the screen.
I'm going to reload the laptop again and disable yum updates of the kernel and logrotate to see what happens....
logrotate-3.7.1-6.RHEL4.i386.rpm should fix the logrotate problem. A yum updated logrotate was using /tmp for the temporary scripts. This directory shouldn't have executable permisions for security reasons. My understanding is that the postrotate scripts weren't restarting syslogd. You'd see ALERT messages in /var/log/messages if you were experiencing this problem.
...and unfortunately three boxes were still locking up after doing an rpm update of logrotate. It was hard to catch but looks like the culprit is the 2.6.9-42.0.3.EL kernel. The only clues I'd see in the logs is that syslogd was restarted. A video monitor attached to one box is blank. I loaded CactiEZ onto a laptop, gave it an IP address and let it sit for a few days without making any changes. It locked up last night and had a "Kernel panic - not syncing: Fatal exception" on the screen.
I'm going to reload the laptop again and disable yum updates of the kernel and logrotate to see what happens....
Reloaded the laptop and it hasn't locked up (no updates). Also loaded the new beta CactiEZ on the little EPIA VIA M10000 and it seems to be working fine even though it's the same kernel & logrotate versions that I blamed for the lockups. One more box to do sometime this week if I get a chance and hopefully everything will be fine.
Normally it works great. I got one initially to have something small to test with on my desk. Had to upgrade the BIOS to load FC5 on one once, but it would boot off a Knoppix CD with no problem. I have one at home that I run Squid with adzapper & Cacti. I put another one together for my wife & it's running ASSP. Have a Gig of memory in it but I think there's a memory leak and that's why that one it's locking up.
When you install certain versions of linux you have to specify "linux nofb". I have used one for a spare workstation at home when my primary craps out.
I've picked up some old Nortel 100S's on ebay that were dead, cut out the back with a dremel for the connector plate, got some power supplies that I could take the guts out of and mounted them in the chassis. Then set the BIOS to power up on power restore and basically have an "appliance". Not nearly as cool as the "Vesputer" or the mythtv inside the dictionaries.
I appreciate the work you've done on CactiEZ as in the past on severaI occasions had spent hours loading modules, compiling and debugging. Wow. Installed in minutes now!
When you install certain versions of linux you have to specify "linux nofb". I have used one for a spare workstation at home when my primary craps out.
I've picked up some old Nortel 100S's on ebay that were dead, cut out the back with a dremel for the connector plate, got some power supplies that I could take the guts out of and mounted them in the chassis. Then set the BIOS to power up on power restore and basically have an "appliance". Not nearly as cool as the "Vesputer" or the mythtv inside the dictionaries.
I appreciate the work you've done on CactiEZ as in the past on severaI occasions had spent hours loading modules, compiling and debugging. Wow. Installed in minutes now!