Docker VM and Custom Actions

Docker, VM, and custom actions

Configure target workloads only after confirming the monitored interface, direction, period, and threshold. Exceeded User Actions and Reset User Actions are separate global switches. Notifications have their own switches.

Workload behavior

• Docker: stop a selected container when exceeded; start a selected container when the rule returns to normal, if configured.
• VMs: bring discovered network links down/up. These operations change VM connectivity; they do not shut down or start the guest.
• User functions: execute the matching function from dvm-user-actions.sh.

A normal transition follows the rule's configured recovery action. The plugin does not track whether a workload had originally been stopped manually. Notification runs use a process lock to prevent overlapping cron/manual checks from duplicating transition actions.

Settings retain saved interface, container, and VM selections when a target is temporarily unavailable. Such options are labeled unavailable; discovery errors are shown separately from a successful discovery with no targets. Review the warning before saving rather than silently replacing a saved selection.

Transitions, results, and retry

Transition markers suppress repeat actions for an observed state. They are temporary, are cleared during service lifecycle operations, and do not provide permanent once-only delivery across restarts. Failed actions are reported but are not automatically retried on every repeated check.

The service controls show the latest recorded outcome for each rule, including the attempt time and Docker, VM, custom-function, and notification results. Records are temporary and kept under /var/run/dvm/outcomes/; they contain bounded status messages rather than custom-script output. An interrupted attempt is shown as completion unconfirmed and is not replayed automatically.

Use Retry Failed Actions for an eligible failed rule after reviewing the target workloads and syslog. Retry checks the current configuration, custom script contents, and fresh threshold state, and runs only components that previously failed. Changed settings, changed threshold state, successful or incomplete attempts, and unavailable measurements cannot be retried from an old record. A retry is a real workload operation and requires confirmation.

Service Check runs diagnostics without executing actions, sourcing the user actions script, sending notifications, or changing transition/outcome state. It is also available while the service is stopped. Test Configured Actions is separate and runs the real notifier after confirmation. It respects normal transition guards; it does not force previously consumed transitions to repeat.

Diagnostic and real-action controls

Control	What it does
Service Check	Inspects interfaces and previews threshold decisions without actions, notifications, user-script loading, or transition/outcome writes.
Test Configured Actions	Runs the real notifier after confirmation, using normal saved transition guards.
Retry failed actions	Runs only recorded failed components after current configuration/script/threshold checks.

The notifier serializes cron/manual/retry runs with one lock. If outcome recording cannot safely begin, workloads do not run. If completion is unconfirmed, the attempt stays visible as in progress or completion unconfirmed; it is not automatically replayed. Custom script output is not stored in outcome records; inspect relevant sanitized syslog output when an exit status reports failure.

Test real operations on disposable containers/VMs. A diagnostic preview is not evidence that an actual workload operation succeeded.