Skip to main content
Question

DEPNotify app not launching with Jamf Helper Script

O
Forum|alt.badge.img+14
  • ooshnoo
  • Honored Contributor
  • 351 replies

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

    J
    Forum|alt.badge.img+7
    • jcaleshire
    • Contributor
    • 27 replies
    • August 24, 2021

    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.

    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Author
    • Honored Contributor
    • 351 replies
    • August 24, 2021
    jcaleshire wrote:

    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.


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

    "Waiting for DEPNotify to start to gather the process ID"
    J
    Forum|alt.badge.img+7
    • jcaleshire
    • Contributor
    • 27 replies
    • August 24, 2021
    ooshnoo wrote:

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

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

    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.

    E
    Forum|alt.badge.img+8
    • efil4xiN
    • Valued Contributor
    • 106 replies
    • August 24, 2021

    What are your flags after --args?

    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Author
    • Honored Contributor
    • 351 replies
    • August 24, 2021
    jcaleshire wrote:

    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.


    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"
    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Author
    • Honored Contributor
    • 351 replies
    • August 25, 2021
    efil4xiN wrote:

    What are your flags after --args?


    @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"
    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Author
    • Honored Contributor
    • 351 replies
    • August 25, 2021

    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
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • August 25, 2021

    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.

    O
    1 person likes this
    • O
      ooshnoo
    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Author
    • Honored Contributor
    • 351 replies
    • August 26, 2021
    mm2270 wrote:

    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.


    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?

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings