Restart QRadar services

Restart QRadar services. Whenever, you notice that no events or flows are visible on interface,  try to restart services. Even if this process would not be successful for you, then the action, will generate some entries in logs, which can help resolve an issue.

There are three main services running in QRadar:

  • Hostcontext
  • Tomcat
  • Hostservices

Each QRadar admin should know these first steps of troubleshooting. Please note, that very important is order of steps and stop hostcontext and tomcat first, before you restart of hostservices.

SSH to the QRadar console or the component, which is not sending events and issue the following commands. If you could see any error during the process then contact with support.

Obviously, you can omit tomcat, if you are restarting services on other component than console (tomcat is running only on console).

For QRadar 7.2.8 and below

# service hostcontext stop
# service tomcat stop
# service hostservices stop
# service hostservices start
# service tomcat start
# service hostcontext start

For QRadar 7.3 and above

# systemctl stop hostcontext
# systemctl stop tomcat
# systemctl stop hostservices
# systemctl start hostservices
# systemctl start tomcat
# systemctl start hostcontext

The hostcontext process is the first step if you restart QRadar services. It is the primary process, that runs on the console and each managed host, and controls all the core qradar processes. Hostcontext

If you can’t deploy changes to one of components then check if there is hostcontext running on. You can use the following command to check hostcontext on each component at once:

# /opt/qradar/support/all_servers.sh -C "systemctl status hostcontext"
or for QRadar 7.2
# /opt/qradar/support/all_servers.sh -C "service hostcontext status"

If you restart hostcontext – you restart also other services dependent on  hostcontext. List of some of them is below:

  • Event Correlation Service
    • ecs-ec (Event Correlation Service – Event Collector)
    • ecs-ep (Event Correlation Service – Event Processor)
  • Accumulator
  • Accumlator_rollup
  • Ariel Database
    • ariel_proxy_server (running only on Console, and not on EP)
    • ariel_query_server (running only on Managed Hosts, and not on Console)
  • reporting_executor
  • report_runner
  • arc_builder (QVM only)
  • Historical Correlation Processor
  • QFlow
  • VIS (vulnerability Integration Services)
  • Asset Profiler
  • Offline Forwarder
  • Tunnels

Depends on your configuration and number of Managed Hosts, each deployment can have different set of hostcontext’s component processes running.  Exact listing of services running you can find by this command:

# grep COMPONENT /opt/qradar/conf/nva.hostcontext.conf

In version QRadar 7.2 you could restart hostcontext without restarting its child processes, using command “hostcontext -q”. This command restarts hostconext service but it keeps data collection going because it is not restarting ecs-ec. This should only be done if you believe there’s an issue with configservices, where the console is not able to update the remote host with the latest config or if you believe the host isn’t responding to deploy requests.

All sub-components/processes/services within Hostcontext can be restarted individually (without restarting hostcontext as a whole) like ecs-ec in the example below:

For QRadar versions prior to 7.3:
# service ecs-ec (stop, start, restart, status)

̶For QRadar versions 7.3 and post:
systemctl (stop, start, restart, status) ecs-ec

The tomcat process is the next if you restart QRadar services. It is responsible for running display engine (GUI) as implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies. Tomcat

  • These specifications are developed under the Java Community Process. Tomcat serves up our jsp webpages (console) as well as RPC and API calls. Restarting of Tomcat also restarts httpd service, but in many cases restart of httpd can be enough to resolve issue.

 

The hostservices is a java process, that runs as an on-going daemon. Hostcontext
It keeps track of 2 other running processes, IMQ and Postgresql. Postgres database stores configuration and reference data about log sources, the deployment, assets, offense data and more. There are some variants of postgres service, which are running on specific appliances like postgres-qvm (QVM), postgres-rm (on QRM) or postgres-qf (on QRIF).

Message Queues (IMQ) opens random ports for communication between components on a managed host. You can view the random port assignments for IMQ using telnet to connect to the local host and doing a look up on the port number. Random port associations are not static port numbers. If a service restarts, then ports re-generated for the service and the service has a new set of port numbers.  IMQ logs you can find in the following location:

#/opt/openmq/mq/var/instances/imqbroker/log/

Terms and Conditions