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 (based on the service you are using: Imunify360 or ImunifyAV(+)):
| Imunify360 | ImunifyAV(+) |
# service imunify360 status |
# 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:
| Imunify360 | ImunifyAV(+) |
# service imunify360 start |
# 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.
| Imunify360 | ImunifyAV(+) |
# service imunify360 status -l |
# service imunify-antivirus status -l |
Example output:
[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[1]: Starting Imunify360 agent… May 13 02:58:43 host.domain.com systemd[1]: Started Imunify360 agent. May 13 02:58:43 host.domain.com imunify-service[4072717]: Starting migrations May 13 02:58:43 host.domain.com imunify-service[4072717]: 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:
|
Imunify360 |
# service imunify360 stop
|
|
ImunifyAV(+) |
# service imunify-antivirus stop
|
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
"sqlite3.DatabaseError".
The imunify360.db file is an sqlite3 database the Imunify360 relies on; it contains incidents, malware hits/lists, settings, etc. Using this workaround will force the database recreation:
|
Imunify360 |
# service imunify360 stop
|
|
ImunifyAV(+) |
# service imunify-antivirus stop
|
If you face any difficulties during the progress or simply cannot make the agent start, please run
|
Imunify360 |
ImunifyAV(+) |
# imunify360-agent doctor |
# imunify-antivirus doctor |
and provide the output to our Support Team at https://cloudlinux.zendesk.com/hc/requests/new.