Any installation from Self Service stuck on Executing forever. Is there way to troubleshoot?

[btomic]

As of today, anything I want to install from Self Service is eternally stuck on Executing. It seems to work just fine for everyone else in the company. Is there anything I can do to troubleshoot this? How can I tell what it gets stuck on? Any log anywhere?

[sdagley]

@blackholemac Is there any reason you're sticking with strictly SMB shares over http/https for an on-prem DP? My experience in switching to the latter was that downloads run significantly faster (it's just a download, no need to mount the file system as with SMB). Resumable downloads are also a nice feature with http/https enabled.

[mking529]

I have never allowed spaces in our network equipment names, so sadly no dice for us. Sad to hear this still exists in 10.14. We're still running 10.11.1 as well just because I don't wanna risk running into any new bugs until all our student machines are provisioned and handed out. At least now I know I'm not missing anything on this issue. I feel for my tech guy provisioning about 370 new machines right now, though. All he needs is one more hoop to jump through. coughmanwemissimagingcough

[AVmcclint]

Add me to the "Me too" list. I've had a handful of Macs experience this problem ever since we upgraded from JSS 10.9.0 to 10.13.0. We can't have any users without the ability to use Self Service even for a single day. This really sucks.

As soon as I saw com.jamf.management.daemon.selfservice was invalidated in the log I had this sinking feeling in my gut. I've deleted and reinstalled the Self Service app, purged caches, deleted preferences and Application support files with no success at all. I've upgraded from High Sierra to Mojave. Nothing seems to fix this at all.

[benducklow]

I heard from Jamf support yesterday that they are stating that PI-006961 has been resolved with v10.14.0... This is the first I have heard of that PI, but the description is "A Self Service policy (or patch policy) can hang/fail to execute when it attempts to run a policy or patch policy and the computer checks in at the same time".

There's really no way for me to validate or confirm this until we get on v10.14.0 however... Thought I would share.

[AdamCraig]

our jamf cloud account is on 10.14.0-t1563397490 and I just saw this issue occur again. I still have that script @benducklow posted way above this on a trigger and running it from terminal still fixes the issue.

[edickson]

I've seen a remove framework/reinstall Self Service fix the issue but I'm not sure it doesn't return some time later.

[Baker]

Is JAMF still looking into this matter. Finding it hard to troubleshoot as we primarily use the Cloud instance for our distribution.

[michaeloswell]

Had this before. Just removed Self Service from Applications and then did sudo jamf policy and it reinstalled it, fixing the issue.

Probably not the best solution but it works.

[AVmcclint]

I think part of the problem is that there may be different causes with the same symptom. I've deleted and reinstalled Self Service with no change. I've run the script provided by @benducklow with no change. I've purged caches and deleted support files. Absolutely nothing fixes it for me.
This is the log from when ANY policy is attempted.

[2019-08-15 09:43:37] Application successfully launched
[2019-08-15 09:43:38] registered for remote notifications
[2019-08-15 09:43:38] JSS Connectivity State change - state: negotiating, user: nil
[2019-08-15 09:43:38] JSS Connectivity State change - state: active, user: nil
[2019-08-15 09:43:38] Request: updateDevicePushToken
[2019-08-15 09:43:38] Request: getJSSDeviceInfo
[2019-08-15 09:43:39] Request: getAppSettings
[2019-08-15 09:43:39] Request: getConfigProfiles
[2019-08-15 09:43:39] Request: getVPPAccounts
[2019-08-15 09:43:39] Request: getPolicies
[2019-08-15 09:43:39] Request: getCategories
[2019-08-15 09:43:39] Request: getBookmarks
[2019-08-15 09:43:39] Request: getEbooks
[2019-08-15 09:43:39] Request: getJSSNotifications
[2019-08-15 09:43:39] Request: getExecutablePatches
[2019-08-15 09:43:39] Request: getMacApps
[2019-08-15 09:43:39] Request: getPatchHistory
[2019-08-15 09:43:39] Request: getPolicyHistory
[2019-08-15 09:43:40] Binary Request: doBrandAppIcon
[2019-08-15 09:43:40] Error updating finder icon: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process.}
[2019-08-15 09:43:45] Binary Request: triggerPolicy
[2019-08-15 09:43:45] Error triggering policy id:437 error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process.}

[benducklow]

@AVmcclint totally agree with you about there "may be different causes with the same symptom". Perhaps explains why some folks are seeing this still on 10.14.0 and the fact I have 2 different PI's with this discussion...

[sgayden]

@tpope This is one of the errors we're seeing in the JAMF log.

[ferrispd]

@michaeloswell Unfortunately did not work for me. Only thing that has worked so far has been to remove the jamf framework and then enroll the device.

[Wasim1]

I had this issue show up today and the only resolution I found was mentioned here before, removing the Jamf Framework and then re-enrolling the machine :)

[colonelpanic]

Check out the contents of /Library/LaunchDaemons/com.jamf.management.daemon.plist

MachServices should look like this:

    MachServices =     {
        "com.jamf.management.daemon.aad" = 1;
        "com.jamf.management.daemon.binary" = 1;
        "com.jamf.management.daemon.selfservice" = 1;
        "com.jamf.management.daemon.service" = 1;
    };

If it doesn't, unload the launchdaemon, (sudo launchctl unload /Library/LaunchDaemons/com.jamf.management.daemon.plist) and modify it so it looks like that (likely issue is that com.jamf.management.daemon.binary is missing and com.jamf.management.daemon.agent is in its place). Next load the LaunchDaemon again (sudo launchctl load /Library/LaunchDaemons/com.jamf.management.daemon.plist) and Self Service should work.

[AVmcclint]

@colonelpanic I took a look at the affected Mac and here's what MachServices in com.jamf.management.daemon.plist looks like

    <key>MachServices</key>
        <dict>
                <key>com.jamf.management.daemon.aad</key>
                <true/>
                <key>com.jamf.management.daemon.selfsevice</key>
                <true/>
                <key>com.jamf.management.daemon.agent</key>
                <true/>
                <key>com.jamf.management.daemon.binary</key>
                <true/>

I changed "agent" to "service" since that's what's different, but it has the same results.

[jhalvorson]

Jamf 10.11.1 with a MacOS 10.14.6 that is experiencing the error when trying anything in Self Service:

Binary Request: triggerPolicy [2019-08-15 09:43:45] Error triggering policy id:437 error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process.}

Here is part of the com.jamf.management.daemon.plist from a Mac has a working Self Service:

<key>MachServices</key>
    <dict>
        <key>com.jamf.management.daemon.aad</key>
        <true/>
        <key>com.jamf.management.daemon.selfservice</key>
        <true/>
        <key>com.jamf.management.daemon.agent</key>
        <true/>
        <key>com.jamf.management.daemon.binary</key>
        <true/>
        <key>com.jamf.management.daemon.service</key>
        <true/>
    </dict>

Here is part of the plist from a non-working Self service

<key>MachServices</key>
    <dict>
        <key>com.jamf.management.daemon.aad</key>
        <true/>
        <key>com.jamf.management.daemon.selfservice</key>
        <true/>
        <key>com.jamf.management.daemon.agent</key>
        <true/>
        <key>com.jamf.management.daemon.binary</key>
        <true/>
    </dict>

Seems odd that it is missing the key for the .service? It only has four out of the five keys that appear on a device that has properly functioning Self Service app.

On the problem device, I re-enrolled it and now it has all five keys in the .plist. Self Service functions now. (I should have simply tried to add that missing key for the .service daemon.)

I recall that if you delete some select .plist related to Jamf and then run the

sudo jamf manage

command, it will download fresh copies of some of the .plist. Next time I witness this issue, I might test that as a method

[ninxsoft]

For what it's worth, our Anti-Virus was blocking the jamfaudit process after an upgrade to Jamf Pro 10.15.0:

/Library/Application Support/JAMF/Jamf.app/Contents/Frameworks/JamfAudit.framework/Versions/A/JamfAudit

Whitelisting this process fixed the problem, policies are now executing correctly via Self Service.

[Jalves]

I ran into this issue today with our self service printers. We really have nothing in these policies except for a printer mapping, and a Complete Message set in User Interaction. I noticed that the printer was successfully installing, but just not reporting back or finishing the policy in the Jamf.log. When I disable the User interaction message in the policy, the stuck executing problem is gone entirely, and printers install in seconds. When I add some text back to it, I'm stuck back in executing. I don't mind removing the User Interaction messages from all my policies, but I'd rather not if possible. Clients are on 10.14.6 and JSS is 10.13.

[AVmcclint]

I discovered that the problem manifested itself right after upgrading to 10.13.0... I am glad to report that upgrading to 10.16.0 fixed it for affected Macs.

[jared_f]

We seem to be running into this issue campus wide again since our Jamf Cloud was upgraded to 10.16.1. We are going to whitelist these paths and see if that resolves it.

/Library/Application Support/JAMF

/usr/local/jamf

/Library/Application Support/JAMF/Jamf.app/Contents/Frameworks/JamfAudit.framework/Versions/A/JamfAudit
^We already has this one whitelisted.

[benducklow]

Thanks for for feedback, @jared_f . I am in the midst of upgrading my TEST and DEV environments with 10.16.1, but havent really seen the issue (at least as much) in 10.15.1... Can others out there confirm whether they are seeing it in 10.16.1 as well along with @jared_f ? I'd dread to bring that issue back up in our Production environment...

[agetz]

I was having this issue on one today and was able to resolve it with the following:
Unload the plist via (sudo launchctl unload /Library/LaunchDaemons/com.jamf.management.daemon.plist)
Move the plist to the trash
Run (sudo jamf manage) to reinstall the plist

I didn't notice any difference in the plists. They were both missing the service key.

Edit: We are on 10.13.1 running 10.14.5-6

[jared_f]

We ran into this campus wide. One of our anti-viruses (Cylance) was picking up Jamf Audit as a threat and quarantined it which broke anything Self Service related. Once our security person whitelisted it, all Self Service policies were able to execute.

[Truex]

For my case, following the note; sudo jamf -removeFramework > restart machine > enroll machine. I was then able to successfully run policies from self service that had previously been hung up at the execution stage.

[discounteggroll]

Thanks Truex,

removing framework, restarting, and re-enrolling instantly fixed the issue of self-service policies hanging on the execution stage on a Mac I just setup.

[jlimonesatwork]

What worked for me was deleting the plist from @jhalvorson comment and running 'sudo jamf manage'. It redownloaded the plist and Self Service started working.

[user-XZGHbaLRFT]

This was a terrific thread, and I wanted to contribute a solution to my specific problem. It seems that somehow i ran a sudo launchctl unload -w /Library/LaunchDaemons/com.jamf.management.daemon.plist in that past. That set the system in a state where the plist would not be loaded. Even when removing that plist and running sudo jamf manage, the plist would be restored but the service disable state would be maintained. Also same if jamf framework would be removed and then reinstalled. The fix was simply sudo launchctl load -w /Library/LaunchDaemons/com.jamf.management.daemon.plist. Now all is well.