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== ==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 ==5006== 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
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: %post /sbin/chkconfig --add cacti /sbin/service denyhosts condrestart exit 0 %preun if [ $1 = 0 ]; then /sbin/service cacti stop > /dev/null 2>&1 /sbin/chkconfig --del cacti fi exit 0 Voila, chkconfig-controlled cacti cron job.
Created attachment 124865 [details] init.d file for cacti
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/
It was discussed on the list a bit: https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01337.html 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.
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 system-config-services). "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).
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"