LaunchDaemon - Stops triggering on schedule

[blakeusblade]

The launcdaemon eventually stops working on schedule for some unknown reason. An article seen points to the issue of launchdaemons with calendar schedules sometimes stop working... which suggests to point to an apple problem.

[blakeusblade]

A work around I've developed below...

Create an EA in jamf to collect when the super log was last modified as this will give you an inderstanding if super is running. Example below...

Name: SUPERMAN - Last Runtime Description: Gets the modified date of the SUPERMAN (/Library/Management/super/super.log) log file. This indicates that the SUPERMAN framework is running. DataType: Date (YYYY-MM-DD hh:mm:ss) Script:

!/bin/sh

RESULT="" if [ -f /Library/Management/super/super.log ]; then RESULT=$(stat -f "%Sm" -t "%Y-%m-%d %H:%M:%S" /Library/Management/super/super.log) fi echo "$RESULT"

Create a smartgoup with the criteria of more than x days ago. I've set 3 days.

Create a policy targeting your smartgroup created above with Triggers: Network change state, Recurring Checkin Execution Frequency: Once every day Files and Processes: Execute Command: super --allow-upgrade-off --user-auth-mdm-failover=ALWAYS

(You dont have to use my command above, you can use whatever super paramaters you like)

Assuming your collectiong inventory once per day with jamf, if super hasn't run in over 3 days, the policy will kick super to run when it falls into the smartgroup. Then fall out of the smartgroup when super has performed a run.

[Macjutsu]

As it turns out... calendar-based LaunchDaemons are unreliable.

A future version of super will replace the entire mechanism with one that is based on a recurring check-in.

[wakco]

I've mentioned my work around on MacAdmins slack (in a thread), but here it is again, where I use a jamf command to create a repeating launched.plist to start super/usr/local/bin/jamf scheduledTask -command "/Library/Management/super/super-starter" -name super-update -runAtLoad -minute '*/1440/' which creates the necessary plist in /Library/LaunchDaemons/com.jamfsoftware.task.super-update.plist, which looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.jamfsoftware.task.super-update</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/Management/super/super-starter</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StartInterval</key>
    <integer>86400</integer>
</dict>
</plist>

As you can see, it repeats once a day.

[bbenkle]

I've mentioned my work around on MacAdmins slack (in a thread), but here it is again, where I use a jamf command to create a repeating launched.plist to start super/usr/local/bin/jamf scheduledTask -command "/usr/local/bin/super-starter" -name super-update -runAtLoad -minute '*/1440/' which creates the necessary plist in /Library/LaunchDaemons/com.jamfsoftware.task.super-update.plist, which looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.jamfsoftware.task.super-update</string>
  <key>ProgramArguments</key>
  <array>
      <string>/Library/Management/super/super-starter</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

As you can see, it repeats once a day.

Looking at this to test with and on 3.0b12 I do not see a symlink of super-starter in /usr/local/bin. Are you performing the symlink creation manually?

Also, how does this work when there is an update to be performed and the user has already deferred for the day? Will it prompt the user again and set a new pending date?

[Macjutsu]

Again, I plan on completely replacing the LD architecture in v4.

As for the symlink question... I'm not sure what your talking about... I've never made a symlink for super-starter.... you can just put a path to the "real" one in /Library/Management.

As for you last question... super literally destroys/creates new LDs on every run for different calendar events... that's how it can get a way with arbitrary deferrals (sometimes two minutes, sometimes two days).... thus you can't just "insert an StartInterval LD here" to replace the current super LD mechanism. They are literally two completely different LD styles.

It will take a significant rewrite of a LOT of super logic to implement StartInterval LDs... thus... next major version.

[wakco]

@bbenkle apologies for the typo, the launchd plist had the correct path. I have corrected the comment.

[bbenkle]

@Macjutsu sorry I was referencing @wakco's workaround for the LDs failure to recheck. Again, thanks for all the work you on this.

[Macjutsu]

https://github.com/Macjutsu/super/releases/tag/v4.0.0-beta1