Feature request - Detect/report errors for shell commands #115

New Issue

michael · 2026-01-19T18:31:35Z

michael commented

2026-01-19 18:31:35 +00:00

Originally created by @camguise on GitHub.

It would be great if JSM could identify when a script that has been run via the "shell" enrollment actions. In the most simple form this could just be putting a red X rather than the green tick on any items which exit with a non-zero exit code.

For devices that are being provisioned by end users they would hopefully see the red X and reach out to support to check the full logs. Those being provisioned by IT staff could investigate the logs themselves and it may be a simple case of going into recovery and removing /Volumes/Macintosh\ HD/private/var/db/.JamfSetupEnrollmentDone to let JSM run again or just wiping and re-provisioning the device.

If it helps for testing a simple enrolment item that produces an error could be achieved with the XML below:

<key>enrollmentActions</key>
<array>
  <dict>
	<key>shell</key>
	<string>/bin/bash</string>
	<key>arguments</key>
	<array>
	  <string>-c</string>
	  <string>exit 1</string>
	</array>
	<key>label</key>
	<string>Testing Error</string>
	<key>requiresRoot</key>
	<false/>
  </dict>
</array>

Originally created by @camguise on GitHub. It would be great if JSM could identify when a script that has been run via the "shell" enrollment actions. In the most simple form this could just be putting a red X rather than the green tick on any items which exit with a non-zero exit code. For devices that are being provisioned by end users they would hopefully see the red X and reach out to support to check the full logs. Those being provisioned by IT staff could investigate the logs themselves and it may be a simple case of going into recovery and removing `/Volumes/Macintosh\ HD/private/var/db/.JamfSetupEnrollmentDone` to let JSM run again or just wiping and re-provisioning the device. If it helps for testing a simple enrolment item that produces an error could be achieved with the XML below: ```xml <key>enrollmentActions</key> <array> <dict> <key>shell</key> <string>/bin/bash</string> <key>arguments</key> <array> <string>-c</string> <string>exit 1</string> </array> <key>label</key> <string>Testing Error</string> <key>requiresRoot</key> <false/> </dict> </array> ```

michael added the enhancement label 2026-01-19 18:31:35 +00:00

michael closed this issue

2026-01-19 18:31:35 +00:00

michael commented

2026-01-19 18:31:35 +00:00

@jordanburnette commented on GitHub:

I am also working on a general list of validation methods for this utility and here are a few thoughts that makes sense in my head. In the enrollmentActions key, JSM could support a key called validation that would function the same as the the upper level key so we can keep the whole process contained to a single action (for what the user sees) while running through JSM.

ie.

<key>enrollmentActions</key>
    <array>
      <dict>
        <key>label</key>
        <string>Rosetta</string>
        <key>icon</key>
        <string>/path/to/icon.png</string>
        <key>policy</key>
        <string>rosetta</string>
        <key>validation</key>
          <array>
            <dict>
              <key>shell</key>
	      <string>/usr/local/orgName/script.sh</string>
	      <key>arguments</key>
	        <array>
	          <string>-c</string>
	          <string>exit 1</string>
	        </array>
            </dict>
          </array>
      </dict>
    </array>

Ideally if a validation step fails, we can have a flag to require the policy/command run up to X number of times and if it doesn't complete (or times out after X period per run), write the Label name(s) to a plist somewhere that could then be read by any post-JSM workflows. Since there is a built in recon at the end of the process, this could be leveraged as an EA based on the 'Label' value of the failed item(s).

The way I would consider approaching one of those post-JSM workflows would be to create and load a LD to run once the user gets to the desktop that will kick off SwiftDialog and let the user know things didn't complete successfully. It would read from the previously created plist and use that info to retry installing the failed items while provide additional support resources. This way, the user isn't left with a broken deployment, but the user can still get the resources for help if things don't go perfectly. At the completion, when we know everything is golden, unload and delete the previously created LD.

@jordanburnette commented on GitHub: I am also working on a general list of validation methods for this utility and here are a few thoughts that makes sense in my head. In the `enrollmentActions` key, JSM could support a key called `validation` that would function the same as the the upper level key so we can keep the whole process contained to a single action (for what the user sees) while running through JSM. ie. ``` html <key>enrollmentActions</key> <array> <dict> <key>label</key> <string>Rosetta</string> <key>icon</key> <string>/path/to/icon.png</string> <key>policy</key> <string>rosetta</string> <key>validation</key> <array> <dict> <key>shell</key> <string>/usr/local/orgName/script.sh</string> <key>arguments</key> <array> <string>-c</string> <string>exit 1</string> </array> </dict> </array> </dict> </array> ``` Ideally if a validation step fails, we can have a flag to require the policy/command run up to X number of times and if it doesn't complete (or times out after X period per run), write the Label name(s) to a plist somewhere that could then be read by any post-JSM workflows. Since there is a built in recon at the end of the process, this could be leveraged as an EA based on the 'Label' value of the failed item(s). The way I would consider approaching one of those post-JSM workflows would be to create and load a LD to run once the user gets to the desktop that will kick off SwiftDialog and let the user know things didn't complete successfully. It would read from the previously created plist and use that info to retry installing the failed items while provide additional support resources. This way, the user isn't left with a broken deployment, but the user can still get the resources for help if things don't go perfectly. At the completion, when we know everything is golden, unload and delete the previously created LD.

michael commented

2026-01-19 18:31:35 +00:00

@scriptingosx commented on GitHub:

please test with 1.2 beta

@scriptingosx commented on GitHub: please test with 1.2 beta

michael commented

2026-01-19 18:31:35 +00:00

@scriptingosx commented on GitHub:

#16

@scriptingosx commented on GitHub: #16

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jamf/Setup-Manager#115