New post
Question
· Oct 30, 2016

ISCAgent debug

#System Administration #Mirroring #Caché

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 - http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...). Other parameters I can see by running /usr/local/etc/cachesys/ISCAgentCtrl status:

application_server.interface_address=*
application_server.port=2188
daemonized=yes
mirroring=on
pid=41850
running=yes
version=2015.2.0.664.3

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
Mikhail Khomenko · Oct 30, 2016

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.

 

Thanks!

0 0
Lisa Moak · Nov 1, 2016

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

mirroring.console_logging_enabled=true

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.

0 0
Mikhail Khomenko · Nov 2, 2016

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 )
Thanks!

0 0
Catherine Hooppell · Nov 3, 2016

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:

mirroring.console_logging_enabled=true

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. 

2 0
Mikhail Khomenko · Nov 7, 2016

Lisa and Kate, at first thanks for your answers!

[root@ecp01 log]# cat /etc/iscagent/iscagent.conf
mirroring.console_logging_enabled=true

 

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
mirroring.console_logging_enabled=true
[root@ecp01 log]# systemctl stop ISCAgent
[root@ecp01 log]# systemctl start ISCAgent
[root@ecp01 log]# /usr/local/etc/cachesys/ISCAgentCtrl status
application_server.interface_address=*
application_server.port=2188
daemonized=yes
mirroring=on
pid=2591
running=yes
version=2016.2.0.721.0
 

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.

0 0
Pete Greskoff · Oct 19, 2020

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.

1 0