Set Owl resource alerts and watchdog timing

1. Read the load notification and identify the server and affected account.
2. Open that server’s System Settings → General Settings → Resource thresholds.
3. Set CPU load, memory, disk, disk I/O and inode thresholds, then save.
4. Configure load/resource alerts and delivery under Notification Settings.
5. Watch subsequent measurements and alerts before changing limits again.

Check server scope above this group. These are saved choices, not packaged defaults. CPU load is not a percentage; notification timing and watchdog recovery use separate intervals. Select the image to enlarge it; use your browser's Back command to return.

CPU load is a one-minute load value, not a percentage; the packaged threshold is 3. Resource percentages default to 80%, alert delay to 300 seconds and repeat notification interval to 21600 seconds.

The watchdog checks eligible enabled services and can attempt recovery. Its restart interval defaults to 3600 seconds independently of notification cooldown. Services disabled by their owner should not be activated merely to silence a notice.

Respond to high server load

1. On the affected server, use top or an available htop to identify the busy processes and account. Keep the load notification and observation time.
2. Review that account’s package CPU/RAM limits in Enhance. For a repeat offender, use its website resource overrides rather than reducing every customer’s allocation. Choose limits from measured demand and check the sites afterward.
3. Prefer Owl AutoMySQL for eligible MySQL connections. Its guide also explains manual selection and exclusions; it does not replace account resource limits.
4. Review recent website access logs or LogSpot to identify busy source IPs. Use the worked access-log counting example, then compare request paths, timestamps and legitimate traffic before adding a narrow IP block.
5. If a country policy is appropriate for your audience, follow country access controls, then verify intended access. Request volume alone does not establish abuse.

Check the source before blocking it

Verify the IP’s operator and purpose. Avoid blocking search engines, CDN/proxy addresses or your own cluster servers because they appear frequently in logs.

Choose limits for the actual workload

Review per-user MySQL connection limits with the database administrator instead of applying one value to every server. Keep a memory recovery margin; see Owl and swap. Recheck measurements after changes.

If the load appears to come from cPFence, contact support with the observation time and relevant redacted logs. Application or capacity problems may also need the hosting or database administrator.

Investigate a repeated service alert

The cPFence Owl WatchDog monitors important server services. If an enabled service stops unexpectedly, Owl checks it again, attempts recovery when eligible, and can send a notification through your configured delivery channel.

Services monitored by Owl WatchDog

• SSH and CRON
• Rspamd, Postfix and Dovecot
• Pure-FTP and MySQL
• The detected web server: Apache, LiteSpeed, OLS or Nginx
• DNS and the main control panel
• AppCD, Filerd and Syslog

Only eligible enabled services are monitored on the selected server.

Common and fastest solution: disable unused services

The quickest fix for repeated notices about an unused service is to disable it. First confirm with the panel administrator that it is genuinely unused and that disabling it will not disrupt customers. Use the owning panel’s service controls where available.

For example, a root administrator can disable an unused Rspamd or Apache service on the affected server:

systemctl disable rspamd.service

systemctl disable apache2.service

Run only the command appropriate to that server. Disabling prevents automatic startup and makes Owl skip the service; it does not stop a currently running service. Record the previous state. If the service is required again, restore it through its owning controls and verify it is enabled and running.

Keep required services enabled

Do not disable a required service merely to silence an alert. For example, Rspamd may be part of the server’s mail filtering. Repair the reported failure instead.

How Owl WatchDog monitors services: Rspamd example

1. Check whether Rspamd is enabled:

   systemctl is-enabled rspamd.service

   Owl skips disabled services.

2. If enabled, check whether it is running:

   systemctl is-active rspamd.service

   If it remains inactive on a subsequent check, Owl can attempt recovery. Read the reported result: an attempted restart is not proof that the service became active.

The recovery interval and notification interval are separate in cPFence v4+. The default recovery interval is one hour; repeated notifications follow the configured repeat notification interval and delivery settings, rather than an unconditional hourly email.

Further troubleshooting

To investigate why the service is failing frequently, review its logs:

journalctl -u rspamd.service -b

Track Owl’s real-time activities with:

cpfence --monitor-owl-logs

Use Ctrl+C to leave the log view. Keep the failure time and relevant redacted journal lines. Resolve the reported cause if the service is needed, then check its status and subsequent Owl results. For further assistance, contact support.

Root administrators can also edit alert values in /etc/cpfcli/config.conf: CPULoadAverageThreshold, MEMORY_THRESHOLD, DISK_USAGE_THRESHOLD, DISK_IO_THRESHOLD, INODE_THRESHOLD, time_diff_wait and email_send_interval. The next collection uses the saved threshold values; changing thresholds does not require restarting a service.

For a service that remains unavailable, inspect its status and journal and resolve its reported problem; see Owl status and controls.