Michael, thank you for your email, but a /sbin/service cced.init restart is not a fix. I restarted the whole server. This should include a "/sbin/service cced.init restart" ;)
Not after a server reboot an not after a /sbin/service cced.init restart the status is working. No status information and a manuell check shows only Jan 14 11:24:25 baltours3 cced(smd)[31831]: client [0:31830] has admin rights in /var/log/messages. So no changes. What I did now to fix the issue): - changing the email address for status email notification in the gui - disable status check in the gui - enable status check in the gui Now it is working again. Regards, Dirk ----------------------------------------------- blackpoint GmbH - Friedberger Straße 106 - 61118 Bad Vilbel -----Ursprüngliche Nachricht----- Von: blueonyx-boun...@mail.blueonyx.it [mailto:blueonyx-boun...@mail.blueonyx.it] Im Auftrag von Michael Stauber Gesendet: Donnerstag, 14. Januar 2016 03:44 An: BlueOnyx General Mailing List <blueonyx@mail.blueonyx.it> Betreff: [BlueOnyx:18987] Re: 5208R - Curious behavior of cced Hi Dirk, > Additional I have the issue that the system monitoring have a red star but > for all services no information is available. > A manual status check only gives one line output in the /var/log/messages > file: > > Jan 13 17:46:44 server cced(smd)[3266]: client [0:3265] has admin rights > > And no status indicator is changing... I just had the same on a 5208R of mine, so I could replicate this. When you click on the "Check Status Now" button in the GUI, then the command "/usr/sbin/swatch -c /etc/swatch.conf" is run on the command line through CCEWrapper. This will always generate a notice in /var/log/messages such as this: cced(smd)[3266]: client [0:3265] has admin rights Likewise, in /var/log/secure you see this: Jan 13 21:29:53 5208r ccewrap[3056]: running (/usr/sbin/swatch) But /var/log/messages should also show all the individual SET transaction where ActiveMonitor in CODB is updated with the status checks from swatch. Example for just one of them: client 0:[0:3056]: SET 17 . Email lastChange = 1452738595 currentState = G currentMessage = "[[base-email.amEmailGreen]]" If all you see is "client [0:3265] has admin rights" and none of the status updates, then CCEd needs a restart: /sbin/service cced.init restart Which actually brings me to my next item on the "needs to be fixed"-list: Our mechanism for restarting CCEd after updates needs an improvement. Right now GUI RPM's that need a CCEd restart will issue the restart in their RPM post-install script. But that will not fire if ... a.) CCEd is currently not running b.) The RPM is installed off the CD c.) The YUM update was issued through the GUI d.) Install order of RPM's is different than expected So often we either get no CCEd restart, a restart at the wrong time, multiple restarts (some of them at the right, some at the wrong time) and generally speaking: It's not ideal nor reliable. The suggested fix is that at the end of YUM updates a special YUM plugin will run an extra script. That script will then check if any RPM did set a flag that requires either a CCEd rehash or a CCEd restart. If so, then the rehash or restart will be performed. Python isn't my favourite coding language, but the instructions for writing YUM plugins are pretty straightforward: http://yum.baseurl.org/wiki/WritingYumPlugins I'll get it done and will wiggle it into base-swupdate. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
