Reboot Agent
Reboot Agent schedules a restart of the Banalytics Agent process after a short delay. It shuts down the agent process; bringing it back depends on the external service manager, container runtime, watchdog, or operating system configuration.
Add a controlled agent restart action
Use this action for controlled recovery and maintenance workflows where restarting the whole Banalytics Agent process is appropriate. It is stronger than restarting a task, connector, media source, or component, so it should usually be a last step after narrower recovery actions have failed.
Before using this action remotely, make sure the agent is managed by something that restarts it after termination and that you have an alternative way to reach the device if the agent does not come back.
Confirm restart supervision
Verify that systemd, a Windows service wrapper, Docker/Kubernetes restart policy, supervisor, or another watchdog will start Banalytics again after the process exits.
Set a short delay
Use Delay (ms) to give the action event and final logs a moment to be emitted before the JVM halts.
Protect the trigger
Restrict manual access and use narrow Event Manager conditions. A broad rule or noisy detector can repeatedly terminate the agent and make the device hard to access.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Delay (ms) | Yes | Delay before the agent process is rebooted, in milliseconds. Valid range: 0-5000. This is a short finalization delay, not a scheduler for long maintenance windows. | 3000 |
Restart the agent process, not the host
When triggered, the action schedules an agent reboot after the configured delay. The agent tries to shut down its services and then forcefully halts the JVM process. Starting the agent again is outside this action and depends on the deployment environment.
This action restarts the Banalytics Agent process only. It does not reboot the host operating system, camera, PLC, gateway, or other device. Use operating-system tooling or device-specific actions for those cases.
Short delayed trigger
The delay is intentionally small so final events and logs have a chance to be emitted before shutdown.
Forceful process halt
The JVM is halted after shutdown handling. This is intentionally forceful and bypasses normal JVM shutdown hooks if the process reaches that point.
External restart required
The agent comes back only when an external process manager, service wrapper, container policy, or watchdog restarts it.
Use reboot for maintenance and last-resort recovery
Manual recovery button
Create a restricted operator action for cases where the agent UI is still reachable but internal integrations, threads, or native resources are in a state that is easier to recover by restarting the whole agent.
Post-upgrade restart
Use it after software upgrade, plugin or module changes, or configuration changes that require a full process restart rather than restarting individual components or tasks.
Last-resort watchdog action
Trigger it from a carefully filtered health-check rule when several recovery attempts have failed, for example after repeated connector failures, persistent source initialization errors, or unrecoverable service state.
Remote maintenance workflow
Combine it with notification actions so operators receive a message before the agent intentionally goes offline for restart.
Delayed restart window
Keep Delay (ms) at a few seconds when the action is triggered from the UI or an action group, giving the action event and final logs a chance to be emitted before the JVM halts.
Operational notes
It is not a host reboot
This action restarts the Banalytics Agent process, not the host operating system and not a camera or device. Use OS tools or device-specific actions for those cases.
The JVM halt is forceful
The JVM is halted after shutdown handling. This is intentionally forceful and can bypass normal JVM shutdown hooks if the process reaches the halt step.
The process manager must bring it back
The agent returns only if it is managed by something that restarts it, such as systemd, a Windows service wrapper, Docker or Kubernetes restart policy, supervisor, or another watchdog.
Delay is short by design
Delay (ms) is limited to 0-5000. It is not meant for scheduling long maintenance windows; use Timeout, scheduler rules, or external orchestration for longer delays.
Use as a final chain action
The action stops downstream task processing after scheduling the reboot, so it should normally be the final action in a chain.
Restart narrower targets first
Avoid using this action as the first recovery step. Prefer restarting the affected task, component, connector, or process first, and use full agent reboot only when local recovery is not enough.
Protect permissions and rules
Protect this action with permissions and narrow Event Manager conditions. A noisy detector, loop, or broad rule can make the agent repeatedly terminate and become hard to access.
Keep alternate access ready
Before enabling remote reboot workflows, make sure there is an alternative way to reach the device or host if the agent does not come back, for example direct SSH, reverse SSH, remote desktop, TeamViewer, local console, or physical access.