Pausing KernelCare automatic updates can be part of a documented maintenance intervention. It also leaves new patches pending, so the pause needs an owner, a deadline and a verified return to normal operation. It should not be used simply to make an error message disappear.
This guide is for the server’s authorized administrator. If your provider manages your cPanel hosting, ask the responsible team to investigate; access to a hosting account does not grant control of the kernel.
Define a limited exception
Before changing anything, record the precise reason, affected machines, person accepting the risk and person responsible for restoring normal operation. Set a review time and conditions for ending the pause early, including an urgent patch release.
- Keep the initial configuration and applied-patch state for comparison after the intervention.
- Define the intended test: reproduce an issue, validate compatibility or follow a support instruction within an agreed scope.
- Arrange monitoring during the pause and a substitute if the owner becomes unavailable.
- If downloads or licensing are failing, start with our connectivity and patch-access guide. Stopping attempts does not fix their cause.
Understand the setting and its limits
The current KernelCare documentation specifies AUTO_UPDATE=False in /etc/sysconfig/kcare/kcare.conf to disable automatic patch application at boot and through cron. This remains valid syntax; assess it in the agent’s effective configuration.
The cron entry can remain present: its automatic invocation then neither downloads nor applies patches. Deleting its file is not a lasting solution, because installing or upgrading the agent can recreate it.
A pause is neither an uninstall nor a rollback of patches already loaded. After a reboot during the pause, patches may not be reapplied automatically: check the kernel now running instead of relying on the previous state. It also does not replace checking other administration mechanisms, manual interventions or operating-system updates. Do not unload patches or unregister licensing merely to arrange a pause.
Account for centralized management
If your environment uses ePortal, distinguish agent settings from patch-feed rules. Downloading and approving deployment on ePortal does not establish that every machine applied the patches. Interpret an old check-in time in light of the active policy too.
Our KernelCare and ePortal guide for isolated networks explains these responsibilities. The ePortal documentation describes feeds and client monitoring. Do not change a central policy without checking which other servers it affects.
Restore and verify normal operation
A deadline written in your request does not reactivate the agent. At the end of the intervention, the administrator must restore the approved setting and policy, for example AUTO_UPDATE=True when automatic updates should be active, then verify that operation has resumed.
- Confirm the patches expected for the kernel actually running and the selected policy.
- Examine agent results and applied patches, rather than relying only on a valid license or a completed process.
- Verify the next automatic cycle and agreed application checks, then record closure of the exception.
An available patch is not necessarily applied. If resumption fails, keep the exception open and have the error investigated. KernelCare does not replace all system maintenance: some updates can still require a reboot.
Plan the intervention with Nuagerie
In your client area, identify the service, reason, intended period and expected checks. Include relevant errors without passwords or license keys. Our team can help define work appropriate to your service’s administration scope and arrange its validation.
