Bug 182033 - Cacti cron script segfaults, pollutes log
Cacti cron script segfaults, pollutes log
Product: Fedora
Classification: Fedora
Component: cacti (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike McGrath
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-02-19 11:01 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 09:01:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
init.d file for cacti (1.06 KB, text/plain)
2006-02-19 13:50 EST, Jason Tibbitts
no flags Details

  None (edit)
Description Ivan Gyurdiev 2006-02-19 11:01:24 EST
PHP Warning:  PHP Startup: ࠊ��+: Unable to initialize module
Module compiled with module API=20041030, debug=0, thread-safety=0
PHP    compiled with module API=20050922, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0
PHP Warning:  mysql_pconnect(): Can't connect to local MySQL server through
socket '/var/lib/mysql/mysql.sock' (2) in
/usr/share/cacti/lib/adodb/drivers/adodb-mysql.inc.php on line 355
PHP Warning:  mysql_pconnect(): Can't connect to local MySQL server through
socket '/var/lib/mysql/mysql.sock' (2) in
/usr/share/cacti/lib/adodb/drivers/adodb-mysql.inc.php on line 355

Segmentation fault

According to valgrind:
==5006== Stack overflow in thread 1: can't grow stack to 0x7FE8018E8
==5006== Process terminating with default action of signal 11 (SIGSEGV)
==5006==  Access not within mapped region at address 0x7FE8018E8
==5006==    at 0x58A3EB: execute (in /usr/bin/php)
==5006== Stack overflow in thread 1: can't grow stack to 0x7FE8018E0

What's broken:
No, I am not running a MySQL server. I have no reason to be running cacti. I
have an "everything" install, and I disable the services I don't use. I would
appreciate if cron jobs would integrate with chkconfig somehow, so there would
be a way to turn them off that didn't involve editing config files.

However... since there is no such integration, I expect the cron jobs to at
least handle gracefully the case where their corresponding service isn't
running. In this case, the cron job segfaults, which is not a very good recovery.

I get lots of messages in the log:
php[2819]: segfault at 00007fffff07ca28 rip 000000000058a3eb rsp
00007fffff07ca30 error 6
php[4380]: segfault at 00007ffffedf9f44 rip 00002b30b217ecd7 rsp
00007ffffedf9f20 error 6
php[4408]: segfault at 00007ffffeee5ed8 rip 0000000000536c30 rsp
00007ffffeee5ea0 error 6
php[4503]: segfault at 00007ffffed81f48 rip 000000000058a3eb rsp
00007ffffed81f50 error 6
Comment 1 Jason Tibbitts 2006-02-19 13:49:37 EST
I agree heartily with this bug report; simply installing a package shouldn't
cause anything to run without an explicit call to chkconfig.  Fortunately, it is
rather easy to integrate cron-based services with chkconfig.  I did so for
denyhosts following the example set by yum and I just shipped something up for
cacti as well.  Change cacti.cron to:

*/5 * * * *       cacti   [ -f /var/lock/subsys/cacti ] && %{_bindir}/php
%{_datadir}/%{name}/poller.php > /dev/null 2>&1

(Maybe change "/var" to "%{_localstatedir}" if you like to be verbose.)  Then
install the attached cacti.init as %{_initrddir}/cacti.  You'll also need to add
this to the specfile:

/sbin/chkconfig --add cacti
/sbin/service denyhosts condrestart
exit 0

if [ $1 = 0 ]; then
  /sbin/service cacti stop > /dev/null 2>&1
  /sbin/chkconfig --del cacti
exit 0

Voila, chkconfig-controlled cacti cron job.
Comment 2 Jason Tibbitts 2006-02-19 13:50:15 EST
Created attachment 124865 [details]
init.d file for cacti
Comment 3 Mike McGrath 2006-02-20 05:08:55 EST
I've posted to the extras-list concerning this so I'll wait to see what ideas
come out of that.  I have a feeling that I'll just end up moving the
cron.d/cacti script to /usr/share/doc/cacti/cron.cacti and including in the
install guide to move it to /etc/cron.d/
Comment 4 Mike McGrath 2006-02-21 09:01:02 EST
It was discussed on the list a bit: 


I've decided I'll just comment out the Cron job and include directions for
enabling it.  I don't think that the "yum" method as it was refered to in the
list is quite a right fit for this instance.  As was mentioned it would still
clog up the logs every 5 minutes.  Seeing as excess logging was the initial
complaint for the bug I think this is an easy and reasonable solution.
Comment 5 Ivan Gyurdiev 2006-02-21 09:06:28 EST
That's fundamentally wrong if you ask me, the entire service management
interface needs to be managed from a single point-and-click application (like

"Reading directions" is something I am not interested in doing. I want to click
on the checkbox, and my application to work. (Then again, I don't use cacti, so
feel free to ignore my advice if you disagree).
Comment 6 Mike McGrath 2006-02-21 09:34:01 EST
Meh, in order for this application to work it requires configuration.  It
doesn't work out of the box because it requires a database to be configured. 
(Which is why this bug exists).  I'm all for making things easy on the user but
cacti is not a daemon nor should it be treated as such.  cron.daily, for
example, is not listed in the "point-and-click application".  The cron script is
only included because it makes it easier on the user to run the poller.  Since
it doesn't work by default disabling it is the best option.

If FE wants to make a policy about this I'll happily change what I'm doing but I
need further discussion into what is best practice, not just "yum does it" and
"I don't like to read"

Note You need to log in before you can comment on or make changes to this bug.