Small improvements to troubleshooting guidance based on a blog post (#3044)

Author: egorpavlikhin

src/pages/docs/octopus-rest-api/examples/index.md

@@ -87,3 +87,7 @@ Explore the REST API examples further in this section:
 - [Users and Teams](/docs/octopus-rest-api/examples/users-and-teams)
 - [Variables](/docs/octopus-rest-api/examples/variables)
 - [Bulk Operations](/docs/octopus-rest-api/examples/bulk-operations)
+
+## Get help from the community
+
+If you're looking for help with API scripts or want to share your own, join the [Octopus Community Slack channel](https://octopus.com/slack). It's a great place to get inspiration, ask questions, and connect with other Octopus users and employees.

src/pages/docs/support/debug-problems-with-octopus-variables.md

@@ -9,16 +9,22 @@ navOrder: 1
 
 Sometimes a variable used during deployment may have a different value from the one you expect. Here are the first steps to debugging these issues.
 
+Project variables and [library variable set](/docs/projects/variables/library-variable-sets) variables are captured in a snapshot when you create a release or publish a runbook snapshot. If you update a variable after the snapshot is taken, the change won't apply to existing releases or snapshots. To pick up the new value, you'll need to either create a new release (or update the existing release's variable snapshot) for deployments, or create and publish a new runbook snapshot for runbooks.
+
 ## Check the variable snapshot for the release {#check-variable-snapshot-for-release}
 
 1. Open the **Project ➜ Releases ➜ Release** page for the Release you are debugging.
 2. Scroll down to find the **Variables** section and click the **Show Snapshot** link so see the snapshot of Variables being used by this Release.
 3. If the variable is wrong in the Snapshot:
-    * Update the Variable in the **Variables** section of the project, and then.
-    * Click the **Update variables** button - beware this will update **all** variables in the Snapshot to the latest values.
+    - Update the Variable in the **Variables** section of the project, and then.
+    - Click the **Update variables** button - beware this will update **all** variables in the Snapshot to the latest values.
 
 :::figure
-![](/docs/img/support/images/3278466.png)
+![Release variable snapshot showing the Update Variables button](/docs/img/support/images/3278466.png)
+:::
+
+:::div{.hint}
+**Tenant variables are the exception.** Unlike project and library variable set variables, [tenant variables](/docs/tenants/tenant-variables) are not included in the snapshot. They take effect immediately without needing a new release or snapshot. For more details, see [Tenant variables and snapshots](/docs/tenants/tenant-variables#tenant-variables-and-snapshots).
 :::
 
 ## Check the variable value in the all variables tab {#check-variable-value-in-all-variables-tab}
@@ -27,7 +33,7 @@ Sometimes a variable used during deployment may have a different value from the
 2. Investigate the variables from all possible sources for the project including the project itself, [variable sets](/docs/projects/variables/library-variable-sets/), and [tenants](/docs/tenants).
 
 :::figure
-![](/docs/img/support/images/5865680.png)
+![All Variables tab showing variables from all sources](/docs/img/support/images/5865680.png)
 :::
 
 :::div{.success}
@@ -49,17 +55,26 @@ This will log the variables available at the beginning of each step in the deplo
 It should look like this. You can have as many extra variables as you want besides these two.
 
 :::figure
-![](/docs/img/support/images/evaluatedvars.png)
+![Project variables with OctopusPrintVariables and OctopusPrintEvaluatedVariables set to True](/docs/img/support/images/evaluatedvars.png)
 :::
 
-3. **Create a new release** of the project or **Update the variable snapshot** for the release as shown above.
-4. Deploy the new release.
-5. Enable **Verbose** output on the **Task log** page.
-6. Expand the element corresponding to the Tentacle on which the problem is observed. Two sets of variables will be printed, first, the raw definitions before any substitutions have been performed, then the result of evaluating all variables for deployment.
+1. **Create a new release** of the project or **Update the variable snapshot** for the release as shown above.
+1. Deploy the new release.
+1. Enable **Verbose** output on the **Task log** page.
+1. Expand the element corresponding to the Tentacle on which the problem is observed. Two sets of variables will be printed, first, the raw definitions before any substitutions have been performed, then the result of evaluating all variables for deployment.
 
 :::div{.warning}
 **For debugging only**
 When adding these variables to your project, Octopus will add the following warning to your deployment log
 `20:30:45   Warning  |       OctopusPrintVariables is enabled. This should only be used for debugging problems with variables, and then disabled again for normal deployments.`
 This is because printing variables increases the size of the task logs, and can make your deployments run slower. Don't forget to turn this off when you're finished debugging. These variables are false by default.
 :::
+
+## Use debug mode {#debug-mode}
+
+As an alternative to setting `OctopusPrintVariables` and `OctopusPrintEvaluatedVariables`, you can enable **Debug Mode** when creating a deployment or running a runbook. Debug mode writes detailed variable information to the task log without requiring you to add variables to your project.
+
+- For **project deployments**, you'll find the Debug Mode option on the deployment creation screen.
+- For **runbooks**, click **Show advanced** on the run screen to reveal the Debug Mode option.
+
+Debug mode is a convenient way to get variable diagnostics for a single run without modifying your project's variables.

src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md

@@ -67,6 +67,12 @@ This is generally indicative of an internal error in Octopus. In Octopus Cloud w
 
 If the task appears to hang after a log message output by the Octopus Server or Tentacle, then in most cases the cause is antivirus or anti-malware software interfering with the task. The first step is to determine if your antivirus software is actually affecting your Tasks, and this can easily be done by removing your antivirus protection and confirming whether the tasks continue to be unresponsive.
 
+#### "Bootstrapper did not return the bootstrapper service message" error
+
+If you see the error `Bootstrapper did not return the bootstrapper service message` in your task log, this typically indicates that antivirus or security software is interfering with the deployment. [Calamari](/docs/octopus-rest-api/calamari) is the lightweight bootstrapper that Tentacle invokes for each deployment step. It's installed and updated in the `Tools` folder and runs steps from the `Work` folder within your Tentacle home directory. When security software blocks or delays Calamari's execution, Tentacle can't receive the expected response, causing this error.
+
+To resolve this, configure your antivirus or endpoint protection software to exclude the Tentacle `Tools` and `Work` directories listed below. For detailed guidance, see [configuring malware protection exclusions](/docs/security/hardening-octopus#configure-malware-protection).
+
 If this test shows that antivirus is interfering with your tasks, you may need to configure your antivirus software with the appropriate exclusions to ensure that it does not lock any files owned by Octopus, or affect any running processes initiated by Octopus. Consult your antivirus provider's documentation for more information.
 
 Some examples of directories (and their subdirectories) you could try adding to an allow-list are: