[BlueOnyx:18993] Re: 5208R - Curious behavior of cced

[Dirk Estenfeld]

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-bounces at mail.blueonyx.it [mailto:blueonyx-bounces at mail.blueonyx.it] Im Auftrag von Michael Stauber
Gesendet: Donnerstag, 14. Januar 2016 03:44
An: BlueOnyx General Mailing List <blueonyx at 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 at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx