· Oct 30, 2016

ISCAgent debug

Good day!
Is there an opportunity to debug the ISCAgent behaviour (in Linux)? ISCAgent uses /etc/iscagent/iscagent.conf as configuration file, but in docs I've found a description only for two parameters (port number and interface - Other parameters I can see by running /usr/local/etc/cachesys/ISCAgentCtrl status:


And in /var/log there is a file called iscagent_console.log, which is always empty.
So, the questions are the next. How can I debug ISCAgent behaviour excluding strace usage? Can I add debug level parameter to iscagent.conf and see debug lines in iscagent_console.log?
Thanks a lot!

Discussion (8)1
Log in or sign up to continue

I've found messages from ISCAgent in /var/log/messages. Something like this:

Oct 30 07:26:04 ecp01 ISCAgent[3823]: ISCAgent starting up
Oct 30 07:26:04 ecp01 ISCAgent[3823]: Application server enabled.
Oct 30 07:26:04 ecp01 ISCAgent[3824]: Starting ApplicationServer on *:2188

And I've found in docs that ISCAgent uses syslog system. So I can add to /etc/rsyslog.conf file the next string:

if $programname == 'ISCAgent' then /var/log/iscagent_console.log

Than restart rsyslog. And we get the same messages in iscagent_console.log.

That's fine. The more interesting are messages like this:

Oct 30 07:26:53 ecp01 ISCAgent[3550]: Arbiter client error: Message read failed.


This message appears on system with arbiter when Primary Failover member is halted by reboot or 'init 0' command. I would be glad to know what this message means. So this was the reason of question about ISCAgent debugging.



You can add this line to the iscagent.conf to enable logging to the iscagent_console.log:


You will have to restart the ISCAgent for it to take effect.

If you are rebooting the primary machine then it makes sense for there to be a communication error between the arbiter and the primary which is likely why you see a "message read failed" error. The ISCAgent console logging may not give you any more information in this case, but can be useful with debugging problems in general.

Lisa, thanks for your answer!
I add this string to iscagent.conf, restart ISCAgent but at the first glance can't  see a difference in log file:

Nov  2 12:37:32 localhost ISCAgent[2796]: Starting
Nov  2 12:37:32 localhost ISCAgent[2796]: ISCAgent starting up
Nov  2 12:37:32 localhost ISCAgent[2796]: Application server enabled.
Nov  2 12:37:32 localhost ISCAgent[2797]: Starting ApplicationServer on *:2188


And no new messages when Primary and Backup connected to Arbiter. Just old messages:

Nov  2 12:45:08 localhost ISCAgent[2856]: Serving application: ISC1ARBITER
Nov  2 12:45:24 localhost ISCAgent[2858]: Serving application: ISC1ARBITER


Maybe, I'm doing something wrong )

There are two processes that can log debugging info -- the ISCAgent process itself and the cuxagent processes the ISCAgent starts -- the cuxagent processes are the ones that interact with the instance.

The messages in /var/log/messages are messages logged by the ISCAgent.

When you enable debugging by adding the line:


to the conf file, you are enabling debugging of the cuxagent processes the ISCAgent starts.

The cuxagent debugging is logged to the iscagent_console.log. 

Lisa and Kate, at first thanks for your answers!

[root@ecp01 log]# cat /etc/iscagent/iscagent.conf


I can't see any changes either in /var/log/messages nor in /var/log/iscagent_console.log with or without this line. I have a feeling that this parameter won't work. Example of session:


[root@ecp01 log]# cat /etc/iscagent/iscagent.conf
[root@ecp01 log]# systemctl stop ISCAgent
[root@ecp01 log]# systemctl start ISCAgent
[root@ecp01 log]# /usr/local/etc/cachesys/ISCAgentCtrl status

This parameter is absent in status output.

What about the reason of such interest. Initially I've tried to understand why in Linux with systemd (RHEL 7.2, for example) Backup Failover member (connected to Arbiter) can't takes over Primary when I power off Primary server (additional condition: both Failover members were started by 'ccontrol start' ). There is a WRC 870617. 

But now it's just a interest for better understanding of switching processes.

Are the two mirror members functioning as primary and backup? No members will even attempt to connect to the arbiter until you have a primary and an active backup (because that is the only situation where the arbiter is used). If you do have a primary and active backup, and they aren't connecting to the arbiter, I'd suggest contacting the WRC so that we can take a look at this with you.