The information in this doc is based on Juju version 3.5.5, and may not accurately reflect other versions of Juju.
See also: ssh, debug-code Alias: debug-hooks
Summary
Launch a tmux session to debug hooks and/or actions.
Usage
juju debug-hook [options] <unit name> [hook or action names]
Options
| Flag | Default | Usage |
|---|---|---|
--container |
the container name of the target pod | |
-m, --model |
Model to operate in. Accepts [<controller name>:]<model name>|<model UUID> | |
--no-host-key-checks |
false | Skip host key checking (INSECURE) |
--proxy |
false | Proxy through the API server |
--pty |
<auto> | Enable pseudo-tty allocation |
--remote |
false | Target on the workload or operator pod (k8s-only) |
Examples
Debug all hooks and actions of unit ‘0’:
juju debug-hooks mysql/0
Debug all hooks and actions of the leader:
juju debug-hooks mysql/leader
Debug the ‘config-changed’ hook of unit ‘1’:
juju debug-hooks mysql/1 config-changed
Debug the ‘pull-site’ action and ‘update-status’ hook of unit ‘0’:
juju debug-hooks hello-kubecon/0 pull-site update-status
Details
The command launches a tmux session that will intercept matching hooks and/or actions.
Initially, the tmux session will take you to ‘/var/lib/juju’ or ‘/home/ubuntu’. As soon as a matching hook or action is fired, the tmux session will automatically navigate you to ‘/var/lib/juju/agents/<unit-id>/charm’ with a properly configured environment. Unlike the ‘juju debug-code’ command, the fired hooks and/or actions are not executed directly; instead, the user needs to manually run the dispatch script inside the charm’s directory.
For more details on debugging charm code, see the charm SDK documentation.
Valid unit identifiers are: a standard unit ID, such as mysql/0 or; leader syntax of the form <application>/leader, such as mysql/leader.
If no hook or action is specified, all hooks and actions will be intercepted.
See the “juju help ssh” for information about SSH related options accepted by the debug-hooks command.