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

We've had mixed results reinstalling Selfservice. Get a ticket opened with your SME and ask to be attached to SUSHELP-1117. It is an internal ticket number with their sustaining engineering team.

rsterner Unfortunate for us we are cloud based and have experienced this across all models of Mac's.
I sent off all the logs they wanted and got the Mac back up and running. This time it required a removeframework and re-enroll.
They came back with "we need more logs" so I'll have to wait for another hanging SS.

I just wanted to add something I'm seeing with machines with this issue. When we do an initial "jamf policy" to get Self Service to come down (because Enrollment Complete trigger is still super unreliable, sigh), I get the "upgrading jamfHelper.app" and "upgrading JAMF Notification Service" as seen in this screenshot. I find the messages odd as these are fresh out of the box Macs. Just thought I'd share these in case JAMF is watching this thread. Sadly I am dealing with too many dumpster files right now to open a case, and it seems quite a few already have anyway.

We've seen this same issue on a few machines recently too. No additional information to add, just adding an incident report :/

Hey all, waiting on a fix/explanation for this as well.. Tried to simply install Chrome for a user from Self Service and it hung at Executing for many minutes.. ended up installing manually.

I called back in an (re)opened my old case regarding this issue and like @stuart.harrop suggest, I got linked with SUSHELP-111. So far the response from support is they are looking into it more. In the meantime I keep feeding them the jamf.log/install.log/system.log as I get them from our support team. It seems at this point (we're on v10.11.1) that a removal of the framework and re-enrollment is the only workaround :(

Received a note from our SME. They are looking to implement a fix for Jamf v10.14

We also see this issue since about 1 week. (randomly and only a few devices)
One issue could be fixed with removeFramework and re-enroll. Another one could not be fixed with re-enrollement.

btw...issue is known for more than 1 1/2 years and not fixed by JAMF...sad...

I agree. JAMF and Apple both need to go on a bug squashing spree. Stop adding things, stop changing interfaces, stop making things shiny and just focus on all these little nitty gritty's that are starting to add up to significant frustration. [/soapbox]

Also, we finished our DEP setup and had to do the fix script on I would say 70% of them. Now we're doing some older computers and haven't had one do it so far. Really bizarre.

Yeah I've recently upgraded our Jamf on-prem to 10.13, the upgrade was successful but now we're seeing this issue. As this is a known issue for over a year, can we get someone from Jamf to confirm they're looking into this?

I too had this issue when we upgraded to Jamf Pro 10.14. In my case it was a really offbeat issue that hadn’t happened since we put in Jamf Pro. Policies would from terminal but not from Self Service. I Figured out that the new self service didn’t like spaces in the distribution point share name. Once I figured that out it was an easy fix. Don’t know if that necessarily applies to you, but it did afflict us.

@blackholemac Interesting discovery I guess with the spaces in the Distribution point name. Could you elaborate on that a bit? Not sure if it's a coincidence or what. We don't have any spaces in our DP share name and still see it from time to time; mostly right after we did the last update to 10.11.1 (which we're still on for the time being). Wonder if people are still seeing it with 10.14.0??

We have always had a space in our DP name is the funny thing. I even moved that convention over to our new JSS a few years back. (That part is a long story for another time.) Anyway, all was working hunky-dory until we upgraded before school started. I noticed my self service policies kept erroring out. My push policies were working fine and and if I ran Self Service policies from command line (sudo jamf policy -id <your policy number here>) it would work fine. Only failed in self service. Logs showed that it couldn’t mount the distribution point. I could mount it properly from “Connect to Server” as well. After agonizing over that for a long time trying to figure out why, I tried trying different shares and it still failed. At That point I called Jamf... while waiting on an expert, I tried changing the share point name as a last straw. For the record, Jamf said to try the same thing 10 minutes after I tried that. That was the answer. I’m Lucky in that I am not married to that share point name. I know when building new on prem installs in the future NOT to include a space in the smb distribution point name ever again!

Same issue here. Everything I run from self-service is hung on executing. 10.14 cloud instance. They do run from command line as mentioned above. I'm using Cloud Distribution point. Is there anything else I can try?

@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.

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

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.

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.

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.

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

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

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.

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.}

@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...

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