Having the Imunify service installed, you may come across the situation when the message "Imunify agent is not running" is displayed when you try to access the Dashboard:
First of all, try to check the status of the service via the command line using the following command:
# service imunify-antivirus status
In case you see the agent is inactive:
[root@host ~]# service imunify360 status Redirecting to /bin/systemctl status imunify360.service ● imunify360.service - Imunify360 agent Loaded: loaded (/usr/lib/systemd/system/imunify360.service; disabled; vendor preset: disabled) Active: inactive (dead)
try to start it via the following command:
# service imunify-antivirus start
It may also occur that despite the Imunify’s Dashboard showing the "agent is not running", the service itself is loaded and active.
You can check it with the following command:
# service imunify-antivirus status -l
[root@host ~]# service imunify360 status -l Redirecting to /bin/systemctl status -l imunify360.service ● imunify360.service - Imunify360 agent Loaded: loaded (/usr/lib/systemd/system/imunify360.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2020-05-13 02:58:43 WIB; 3min 54s ago Main PID: 1234567 (python3) Status: "Demonized" CGroup: /system.slice/imunify360.service ├─1234567 /opt/alt/python35/bin/python3 -m im360.run --daemon --pidfile /var/run/imunify360.pid ├─1234568 /usr/bin/tail --follow=name -n0 --retry /usr/local/cpanel/logs/cphulkd.log ├─1234569 /usr/bin/tail --follow=name -n0 --retry /etc/apache2/logs/modsec_audit.log ├─1234570 /usr/bin/tail --follow=name -n0 --retry /var/ossec/logs/alerts/alerts.json └─1234571 /opt/alt/python27/bin/python2.7 -s /usr/sbin/cagefsctl --wait-lock --force-update-etc May 13 02:58:39 host.domain.com systemd: Starting Imunify360 agent… May 13 02:58:43 host.domain.com systemd: Started Imunify360 agent. May 13 02:58:43 host.domain.com imunify-service: Starting migrations May 13 02:58:43 host.domain.com imunify-service: There is nothing to migrate
Most often, such circumstances attest that the Imunify service has been recently installed on the server. Sometimes, a desynchronization between the agent and the web interface may occur in such cases, and it can take a bit of time for the database to be integrated completely.
In case the issue is still the same after 60 minutes, you can try creating the backup of the Imunify files and do the service restart to force the sync process:
# service imunify-antivirus stop # mv /var/imunify360/files /var/imunify360/files_backup # service imunify-antivirus start
After these actions, wait until the files downloading and the migration process are complete – the agent will synchronize with the web interface and start working normally. You can monitor this process via
# tail -f /var/log/imunify360/console.log
Another similar workaround may be handy in case you locate some database-related error inside the
/var/log/imunify360/error.log – by renaming the database file and restarting the service. There may be errors like
"Imunify360 database is corrupt. Application cannot run with corrupt database."
or some lines with
imunify360.db file is an sqlite3 database the Imunify relies on; it contains incidents, malware hits/lists, settings, etc. Using this workaround will force the database recreation:
# service imunify-antivirus stop # mv /var/imunify360/imunify360.db /var/imunify360/imunify360.db_backup # service imunify-antivirus start
If you face any difficulties during the progress or simply cannot make the agent start, please run
# imunify-antivirus doctor
and provide the output to our Support Team at https://cloudlinux.zendesk.com/hc/requests/new.