DEPNotify app not launching with Jamf Helper Script

ooshnoo
Valued Contributor

This is only happening on Big Sur. When using the Jamf starter script, the DEPNotify.app never launches. The code in the script is default as follows:

 

sudo -u "$CURRENT_USER" open -a "$DEP_NOTIFY_APP" --args -path "$DEP_NOTIFY_LOG"

 

however it never actually launches the app. The depnotifyDebub.log file just repeatedly says:

 

"Waiting for DEPNotify to start to gather the process ID"

 

Of course when I launch the DEPNotify.app manually, everything starts to work. Again, this only happens on Big Sur. It works fine on Catalina machines.
Anyone got any idea why the script is no longer launching the DEPNotify.app? I haven’t made any changes to the starter script in months!

9 REPLIES 9

jcaleshire
New Contributor III

Here's the string that I've been using to launch DEPNotify on our Big Sur Macs:

 

sudo -u "$(ls -l /dev/console | awk '{print $3}')" open /Applications/Utilities/DEPNotify.app --args -fullScreen -path "$COMMAND_LOG"

 

It looks pretty much identical, save for the variables. What variable definitions are you using for your CURRENT_USER and DEP_NOTIFY_APP?

 

EDIT:

I actually just realized what the issue is. The -a option for opening a file essentially says "use this app to open the file", instead of "open this app". Since what you are trying to open is an executable, you can drop the -a option and it should work just fine. Right now it's getting a command with what app to use, but it's not receiving an argument to tell it what to actually open.

ooshnoo
Valued Contributor

Thanks man. Unfortunately it didn't work.  Still stuck at 

"Waiting for DEPNotify to start to gather the process ID"

jcaleshire
New Contributor III

Hrm. Just double-checking, but you're not attempting to launch DEPNotify on the login screen, right? I attempted to do that at one point, but it required modification of the app itself to make it work, and I wasn't a huge fan of that.

Since it's still not working, it's sounding like there is and issue with the variables the command is being fed. Assuming this is the DEPNotify-Starter script (found here), it should be using these two definitions:

CURRENT_USER=$(/usr/bin/stat -f "%Su" /dev/console)
DEP_NOTIFY_APP="/Applications/Utilities/DEPNotify.app"

The DEP_NOTIFY_LOG definition isn't super important, but make sure it isn't null, since that would cause the command to fail.

I've run this command on a couple of the machines I have here, and it looks like it's working just fine. I would try running that command on a couple of Macs manually, just to see if the launch command is erroring, or if it's potentially something on the configuration side that's causing it to fail. In my brief experience with the app, I have yet to see it fail to launch because of a config error, but there's a first time for everything, I suppose.

ooshnoo
Valued Contributor

No sir... not attempting to launch DEPNotify on the login screen.  At enrollment, a policy installs the DEPNotify.app, a launchdaemon and a script.  The lauchdaemon is loaded and waits until a user is logged in.  Once it sees a user is logged in, the script continues and and calls the 2nd policy that runs the helper script.  It's basexd on the following:  https://yearofthegeek.net/2018/05/updating-our-depnotify-process/

The script that calls the policy that runs the helper/starter script is as follows:

#!/bin/sh

echo "DEP Provisioning Script Run" >> ~/Desktop/dep.log

# Get the logged in user
CURRENTUSER=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");')
# Setup Done File
setupDone="/var/db/receipts/com.dwr.provisioning.done.bom"

JAMFBIN=/usr/local/jamf/bin/jamf

if pgrep -x "Finder" \
&& pgrep -x "Dock" \
&& [ "$CURRENTUSER" != "_mbsetupuser" ] \
&& [ ! -f "${setupDone}" ]; then

# echo "Logic tests passed - calling depnotify" >> ~/Desktop/dep.log

  # Kill any installer process running
  killall Installer
  # Wait a few seconds
  sleep 5
  
  $JAMFBIN policy -event  allapps-test
  
  # Wait a few seconds
  sleep 5
  # Create a bom file that allow this script to stop launching DEPNotify after done
  /usr/bin/touch /var/db/receipts/com.idg.provisioning.done.bom
  # Remove the Launch Daemon
  /bin/rm -Rf /Library/LaunchDaemons/com.idg.launch.plist

fi
exit 0

 As illustrated in the code above, the policy that runs the starter/helper script has a trigger called "allapps-test", and this is where the DEPNofity.app fails to run and gives the error:

"Waiting for DEPNotify to start to gather the process ID"

efil4xiN
New Contributor III

What are your flags after --args?

ooshnoo
Valued Contributor

@efil4xiN wrote:

What are your flags after --args?


No args set, sir.  just using the default verbage of the script

 

sudo -u "$CURRENT_USER" open -a "$DEP_NOTIFY_APP" --args -path "$DEP_NOTIFY_LOG"

ooshnoo
Valued Contributor

So I've managed get some output of the helper script and here's what I found...again, this is only happening on Big Sur. 

 

Script result: The application /Applications/Utilities/DEPNotify.app cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2561, NSUnderlyingError=0x7f926441ea50 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x7f926441d8f0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 111}}}}}

It says the user does not have permission to launch the app, which I don't understand because it's permissions are 777 

mm2270
Legendary Contributor II

It sounds to me like Big Sur isn't liking how DEPNotify is being launched. I followed your link to the full scripts, and I see that in the script that opens DEPNotify, it uses a line like this:

sudo -u "$CURRENTUSER" /var/tmp/DEPNotify.app/Contents/MacOS/DEPNotify &

If I had to guess, I would say maybe this sudo -u <username> method doesn't work as reliably anymore in Big Sur. Personally that method was always hit or miss for me even in older mac OSes.

To make mine work, I have a LaunchAgent that gets created on the fly in the initial script, and then once the Finder/Dock is active (meaning someone is successfully logged in) I activate the LaunchAgent, which runs as the logged in user to launch DEPNotify. So the LaunchAgent is what's calling DEPNotify, not the main script, trying to launch it as the user. That's all the LaunchAgent does. The rest, in terms of installs of software, updating info inside the DEPNotify window, etc. is all handled by the main script.

However, if you want to keep using that type of process, you could probably update it to use the launchctl asuser type syntax, which still works well in Big Sur in my experience. That might get around the problem you're seeing.

ooshnoo
Valued Contributor

Thanks for the input.  I've tried the "launchctl asuser" syntax as well, and get the same result...specifically this line, which is the default from the latest version of the jamf helper script:

launchctl asuser $CURRENT_USER_ID open -a "$DEP_NOTIFY_APP" --args -path "$DEP_NOTIFY_LOG"

 I'd like to pick your brain more with regards to your setup/workflow if you don't mind.  Any chance you could post your LaunchAgent and/or script that creates it on the fly?