Announcement: Upgrade to macOS Mojave

With features like Dark Mode, Stacks, and four new built-in apps, macOS Mojave helps you get more out of every click. 
Find out how to upgrade to macOS Mojave > https://support.apple.com/macos/mojave

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Question:

Question: launchd StartCalendarInterval doesn't run on time

I cannot get launchd to run a script on time on MacOS 10.8.4. So I created a test script wich did nothing other than print the current time into a text file. Actually, I created two, to see if the "system" one performed differently than the "user" one. The user script is supposed to run on the hour. The system script should run at 5 after. They do not.


The system time is correct. The scripts do not depend on anything which could cause random delays

(like sending email, or other network interactions). It appears, from the logs, that the system is up

during those times.


Here's what the output file looks like.


time from Root log below. Should be on 5.

2013-Jun-29 02:06:23

time from Jason log below. should be on the hour.

time from Root log below. Should be on 5.

2013-Jun-29 03:20:28

2013-Jun-29 03:20:28

time from Root log below. Should be on 5.

time from Jason log below. should be on the hour.

2013-Jun-29 04:19:58

2013-Jun-29 04:19:58

time from Jason log below. should be on the hour.

2013-Jun-29 05:01:03

time from Root log below. Should be on 5.

2013-Jun-29 05:19:27

time from Root log below. Should be on 5.

2013-Jun-29 06:18:57

time from Root log below. Should be on 5.

2013-Jun-29 07:18:27

time from Root log below. Should be on 5.

2013-Jun-29 08:17:57

time from Root log below. Should be on 5.

2013-Jun-29 09:17:27




The scripts are pretty much identical, except for the text printed to the file.


#! /bin/bash


# cd to the logFiles dir

cd /Users/jason/logFiles/


# log date and time to file

echo time from Jason log below. should be on the hour. >> daemonLog.txt

echo $(date +"%Y-%b-%d %H:%M:%S") >> daemonLog.txt


The system.log seems to indicate that the system was up at those times. That is, unless it decided to take random naps around the top of the hour. 🙂 (I'd be surprised if this ClamAV thing was the problem, btw.) But that 08:59:57 message is curious. However Date&Time is set automatically from time.apple.com, and I have checked it against my NTP server at work.


Jun 29 05:35:10 <hostname>.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Library/PrivilegedHelperTools/com.apple.serverd' [70] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (100000,0)

Jun 29 05:40:33 <hostname> freshclam[113]: Your ClamAV installation is OUTDATED!

Jun 29 05:40:33 <hostname> freshclam[113]: Local version: 0.97.6 Recommended version: 0.97.8

Jun 29 07:34:25 <hostname> com.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (2,0)

Jun 29 07:34:25 <hostname> com.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Library/PrivilegedHelperTools/com.apple.serverd' [70] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (100000,0)

Jun 29 07:35:10 <hostname> com.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (2,0)

Jun 29 07:35:10 <hostname> com.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Library/PrivilegedHelperTools/com.apple.serverd' [70] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (100000,0)

Jun 29 07:40:39 <hostname> freshclam[113]: Your ClamAV installation is OUTDATED!

Jun 29 07:40:39 <hostname> freshclam[113]: Local version: 0.97.6 Recommended version: 0.97.8

Jun 29 08:59:57 <hostname> com.apple.time[234]: Interval maximum value is 946100000 seconds (specified value: 9223372036854775807).

Jun 29 09:00:29 --- last message repeated 232 times ---

Jun 29 09:35:10 <hostname> com.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (2,0)

Jun 29 09:35:10 <hostname> com.apple.SecurityServer[20]: Succeeded authorizing right 'system.privilege.admin' by client '/Library/PrivilegedHelperTools/com.apple.serverd' [70] for authorization created by '/Applications/Server.app/Contents/ServerRoot/usr/libexec/ServerEventAgent' [108] (100000,0)


The /var/log/com.apple.launchd.peruser.501 log file seems to show nothing troublesome. (I must admit that I don't know what all this means.)

It doesn't have times to correlate, so I've included the last 20 lines at 2013-Jun-29 12:07.


833735 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG callout: 416

833738 com.apple.launchd.peruser.501 200 com.apple.distnoted.xpc.agent 203 Getting key: 5

833741 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG demux succeeded.

833745 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG request.

834023 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG callout: 416

834028 com.apple.launchd.peruser.501 200 com.apple.distnoted.xpc.agent 203 Getting key: 5

834031 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG demux succeeded.

834035 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG request.

834084 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG callout: 416

834088 com.apple.launchd.peruser.501 200 com.apple.distnoted.xpc.agent 203 Getting key: 5

834091 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG demux succeeded.

834094 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG request.

834693 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG callout: 69

834699 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 Background: Receive right returned to us: com.apple.distributed_notifications@Uv3

834707 com.apple.launchd.peruser.501 200 com.apple.distnoted.xpc.agent 203 Tried to dispatch an already active job: PID is still valid.

834710 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 Background: No submanagers left.

834713 com.apple.launchd.peruser.501 200 com.apple.distnoted.xpc.agent 203 Job is active: PID is still valid

834716 com.apple.launchd.peruser.501 200 com.apple.distnoted.xpc.agent 203 Job was sent SIGTERM.

834718 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG demux succeeded.

834720 com.apple.launchd.peruser.501 200 com.apple.launchd.peruser.501 200 MIG request.


And, finally, here are the plist files. The one called "testDaemonRoot" is the one I put in the system directory with these commands.


605 sudo cp com.jason.testDaemonRoot.plist /Library/LaunchDaemons//

606 launchctl load -w /Library/LaunchDaemons/com.jason.testDaemonRoot.plist


The one called "testDaemonJason" I entered with this command.


597 launchctl load com.jason.testDaemonJason.plist


mini:crons jason$ cat com.jason.testDaemonRoot.plist

<?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.jason.testDaemonRoot</string>

<key>ProgramArguments</key>

<array>

<string>/Users/jason/bin/daemonTestRoot.sh</string>

</array>



<key>StartCalendarInterval</key>

<array>

<dict>

<key>Minute</key>

<integer>5</integer>

</dict>

</array>

</dict>

</plist>


-----------------------------------------------------------------------


mini:crons jason$ cat com.jason.testDaemonJason.plist

<?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.jason.testDaemonJason</string>

<key>ProgramArguments</key>

<array>

<string>/Users/jason/bin/daemonTestJason.sh</string>

</array>



<key>StartCalendarInterval</key>

<array>

<dict>

<key>Hour</key>

<integer>21</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>22</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>23</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>0</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>1</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>2</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>3</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>04</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>05</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

</array>

</dict>

</plist>


-----------------------------------------------------------------------



I hope I've given someone enough information to tell me what's going wrong here. Thanks very much for reading this!

Mac mini, OS X Mountain Lion (10.8.4)

Posted on

Reply
Question marked as Helpful

Jun 29, 2013 4:56 PM in response to JsinJ In response to JsinJ

JsinJ wrote:


(I'd be surprised if this ClamAV thing was the problem, btw.)


Jun 29 07:40:39 <hostname> freshclam[113]: Your ClamAV installation is OUTDATED!

Jun 29 07:40:39 <hostname> freshclam[113]: Local version: 0.97.6 Recommended version: 0.97.8

I take it you are running OS X Mountain Lion Server on your mini.


I would agree that ClamAV®'s version isn't the problem here. Those messages are just from the ClamAV® database update process and hopefully aren't serious. The release note state:

ClamAV 0.97.7 has been released!

March 17th, 2013 Posted by -

Dear ClamAV users,


“ClamAV 0.97.7 addresses several reported potential security bugs. Thanks to

Felix Groebert, Mateusz Jurczyk and Gynvael Coldwind of the Google Security

Team for finding and reporting these issues.”

and

ClamAV 0.97.8 has been released!

April 23rd, 2013 Posted by -

Dear ClamAV users,


“ClamAV 0.97.8 addresses several reported potential security bugs. Thanks to

Felix Groebert of the Google Security Team for finding and reporting these issues.”

I was never able to get any details from the developers on what vulnerabilities were addressed and whether any of them were OS X related (perhaps Apple knows), so you're on your own on whether it's worth the effort to update it or not.


Apple is almost always behind with these 3rd party updates. If you feel the need and have the time I can point you to some instructions for downloading the source code, compiling and installing it for yourself.

There’s more to the conversation

Read all replies

Page content loaded

Question marked as Helpful

Jun 29, 2013 1:12 PM in response to JsinJ In response to JsinJ

Launchd won't run if it is sleeping. It will run all scheduled tasks once it awakes.

You can only set one calendar interval.

You can set it to run every x seconds with the StartInterval parameter.

Jun 29, 2013 1:12 PM

Reply Helpful (1)
Question marked as Helpful

Jun 29, 2013 4:56 PM in response to JsinJ In response to JsinJ

JsinJ wrote:


(I'd be surprised if this ClamAV thing was the problem, btw.)


Jun 29 07:40:39 <hostname> freshclam[113]: Your ClamAV installation is OUTDATED!

Jun 29 07:40:39 <hostname> freshclam[113]: Local version: 0.97.6 Recommended version: 0.97.8

I take it you are running OS X Mountain Lion Server on your mini.


I would agree that ClamAV®'s version isn't the problem here. Those messages are just from the ClamAV® database update process and hopefully aren't serious. The release note state:

ClamAV 0.97.7 has been released!

March 17th, 2013 Posted by -

Dear ClamAV users,


“ClamAV 0.97.7 addresses several reported potential security bugs. Thanks to

Felix Groebert, Mateusz Jurczyk and Gynvael Coldwind of the Google Security

Team for finding and reporting these issues.”

and

ClamAV 0.97.8 has been released!

April 23rd, 2013 Posted by -

Dear ClamAV users,


“ClamAV 0.97.8 addresses several reported potential security bugs. Thanks to

Felix Groebert of the Google Security Team for finding and reporting these issues.”

I was never able to get any details from the developers on what vulnerabilities were addressed and whether any of them were OS X related (perhaps Apple knows), so you're on your own on whether it's worth the effort to update it or not.


Apple is almost always behind with these 3rd party updates. If you feel the need and have the time I can point you to some instructions for downloading the source code, compiling and installing it for yourself.

Jun 29, 2013 4:56 PM

Reply Helpful (1)

Jun 29, 2013 5:36 PM in response to Barney-15E In response to Barney-15E

Barney-15E wrote:


Launchd won't run if it is sleeping. It will run all scheduled tasks once it awakes.


Whoa! There's a surprise. From everything I read, I thought Launchd was a "replacement for Cron" and "Cron was deprecated". But if it only runs when it wakes up, then it doesn't sound like the solution for running things at specific times. (Unless I write a cron job to wake it up:) )


[For the following, I'd be happy to read some documentation rather than bother you. But I haven't found these answers in the Man Page, or any other Docs I've read.]


If I want a program to check a condition at exactly 5am every morning (and another at 06:45, and another at 18:09, and another at at 18:23) should I be using Launchd? Or is Cron the better tool for that?


If I should be using Launchd, is there some way I can insure it is awake?


If I should be using Cron, could you point me at some official declaration of Cron's status (re: deprecated) ?


Thanks for the quick reply to the original post!


----------------------------- unnecessary data below ---------------------


It does seem that cron will wake up Launchd. After posting my original question, I set up a cron job to test that. It writes to the same log as my Launchd job.


time from Root log below. Should be on 5.

2013-Jun-29 13:09:48

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 13:10:00

time from Root log below. Should be on 5.

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 14:10:00

2013-Jun-29 14:10:00

time from Root log below. Should be on 5.

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 15:10:00

2013-Jun-29 15:10:00

time from Root log below. Should be on 5.

2013-Jun-29 16:08:56

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 16:10:00

time from Root log below. Should be on 5.

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 17:10:00

2013-Jun-29 17:10:00

Jun 29, 2013 5:36 PM

Reply Helpful

Jun 29, 2013 6:48 PM in response to JsinJ In response to JsinJ

JsinJ wrote:

From everything I read, I thought Launchd was a "replacement for Cron" and "Cron was deprecated". But if it only runs when it wakes up, then it doesn't sound like the solution for running things at specific times. (Unless I write a cron job to wake it up:) )

All true, but launchd is better, IMHO, because the job will eventually run while cron will just skip if sleeping. I know of no way for a cron job to wake. Cron jobs still work, but just barely and word on the street is that they will be completely gone with Mavericks.

Jun 29, 2013 6:48 PM

Reply Helpful

Jun 29, 2013 9:05 PM in response to JsinJ In response to JsinJ

I don't believe cron will run at all if asleep at the desired time. Launchd will run any missed items once awake.

See info here: http://developer.apple.com/library/mac/ipad/#documentation/MacOSX/Conceptual/BPS ystemStartup/Chapters/CreatingLaunchdJobs.html


Also search "launchd plist" or "launchctl plist" for lots of examples and help.


Lingon is a nice GUI for building them.

Jun 29, 2013 9:05 PM

Reply Helpful

Jun 30, 2013 12:09 AM in response to Barney-15E In response to Barney-15E

Barney-15E and MadMacs0,

please see the "Unnecessary data below" section of my post on Jun 29, 2013 5:36 PM .

Your descriptions of how Cron and Launchd work are exactly opposite of the output from my example Cron and Launchd jobs.


The Cron job ran at 10 minutes after the hour, exactly 10 minutes, not a second late. The Launchd job *never* ran at 5 minutes after the hour. The closest it got was almost 4 minutes late.


What happned most often was that Cron would run at exactly 10 after the hour, and Launchd would run 5 minutes late, exactly at the time Cron ran.


So Barney, "I don't believe cron will run at all if asleep at the desired time." doesn't match the output above. Cron ran on time every time.


And MadMacs, " the job will eventually run while cron will just skip if sleeping. I know of no way for a cron job to wake." doesn't seem accurate because (again) cron ran on time every time. Cron apparently doesn't sleep the way Launchd does.


As further evidence of the apparent reliability of Cron over Launchd, here is the output which followed the post above. Note that the "Jason log" (a Launchd job run from /Library/LaunchDaemons instead of my home directory) comes into the picture. That one is scheduled to run on the hour (between 21:00 and 05:00, as defined in my original post).


In the output below, you will see the Launchd jobs occasionally get close to running on the hour, or at 5 past (for which they are scheduled). But mostly they run when the Cron job runs (at 10 past the hour). The Cron job, which is Rock Solid Reliable to run at exactly 10 past the hour, not a second late.


I'm not claiming that I know more than either of you on this subject. I certainly don't. I'm simply reporting on what happened with my experiment.



time from Root log below. Should be on 5.

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 17:10:00

2013-Jun-29 17:10:00

time from Root log below. Should be on 5.

2013-Jun-29 18:08:43

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 18:10:00

time from Root log below. Should be on 5.

2013-Jun-29 19:06:56

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 19:10:00

time from Root log below. Should be on 5.

2013-Jun-29 20:05:01

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 20:10:00

time from Root log below. Should be on 5.

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 21:10:00

time from Jason log below. should be on the hour.

2013-Jun-29 21:10:01

2013-Jun-29 21:10:01

time from Jason log below. should be on the hour.

time from Root log below. Should be on 5.

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 22:10:00

2013-Jun-29 22:10:00

2013-Jun-29 22:10:00

time from Jason log below. should be on the hour.

2013-Jun-29 23:00:07

time from Root log below. Should be on 5.

2013-Jun-29 23:05:22

time from Cron Job below. should be 10 past the hour.

2013-Jun-29 23:10:00

Jun 30, 2013 12:09 AM

Reply Helpful

Jun 30, 2013 12:52 AM in response to JsinJ In response to JsinJ

JsinJ wrote:

It does seem that cron will wake up Launchd.


I think there must be some misunderstanding here. launchd never sleeps. In fact it is responsible for launching the cron process at startup. Currently in my setup the root launchd has a PID of 1 and cron is 114. The only thing that sleeps is your CPU. To understand what we are saying about cron vs. launchd you will need to put your computer to sleep through one of each events and see what happens when.


Also note that there is a root launchd process that takes care of finishing up initialization of the System then loads all the launch on-demand daemons from /System/Library/LaunchDaemons and /Library/LaunchDaemons, sets up sockets and parameters, then launches those that need to be running all the time. These will run whether a user is logged in or not.


Because launchd registers the sockets and file descriptors used by all daemons before it launches any of them, daemons can be launched in any order. If a request comes in for a daemon that is not yet running, the requesting process is suspended until the target daemon finishes launching and responds.


If a daemon does not receive any requests over a specific period of time, it can choose to shut itself down and release the resources it holds. When this happens, launchd monitors the shutdown and makes a note to launch the daemon again when future requests arrive.


But there are also per-user launchd processes that loads the parameters for each launch-on-demand user agent from the property list files found in /System/Library/LaunchAgents, /Library/LaunchAgents, and the user’s individual Library/LaunchAgents directory. These per-user processes are referred to as user agents. A user agent is essentially identical to a daemon, but is specific to a given logged-in user and executes only while that user is logged in.


I feel confident that you have not properly configured your test daemons, but have no time nor interest in learning how to write them. For the few that I've done I used Lignon just as I had previously used CronniX for all my cron events. It's way too easy to make a mistake.


In a previous entry you said:

here are the plist files. The one called "testDaemonRoot" is the one I put in the system directory with these commands.


605 sudo cp com.jason.testDaemonRoot.plist /Library/LaunchDaemons//

606 launchctl load -w /Library/LaunchDaemons/com.jason.testDaemonRoot.plist


The one called "testDaemonJason" I entered with this command.


597 launchctl load com.jason.testDaemonJason.plist

Since you put those in your system directory you would need to use sudo launchctl to load them into the proper queue. Of course when you reboot your computer they should load into the proper queque by themselves.

Jun 30, 2013 12:52 AM

Reply Helpful

Jul 2, 2013 5:50 PM in response to MadMacs0 In response to MadMacs0

If you think Lignon will solve this sort of thing, I'll give that a shot!Thanks!


I'm assuming, from your answer, that it is possible to get a job to run with precise timing at least once a day (per Launchd entry). If that's the case, I'm also assuming I can use Lignon to do that. If so, no need to reply.


If not, however, and you'd like to point out any inaccuracies in that assumption, or make other suggestions, please do so.


Again, I really appreciate the time everyone has put into these informative answers!

Jul 2, 2013 5:50 PM

Reply Helpful

Jul 2, 2013 6:38 PM in response to JsinJ In response to JsinJ

Lingon just makes it simpler to get a working launchd job. You can then look at the working plist to help understand how to write them.


What was the CalendarInterval dictionary entry for your launchd test?


I've set up your job and the first interval was one second late.


For the timing quesions, this is what is posted in one of the sections of the topic I linked to above:

If the computer is asleep, cron will not run, but launchd will run as soon as it wakes as long as it is a CalendarInterval. If you run it on any other type of schedule, launchd will skip it if asleep.

Effects of Sleeping and Powering Off

If the system is turned off or asleep,

cron
jobs do not execute; they will not run until the next designated time occurs.

If you schedule a

launchd
job by setting the
StartCalendarInterval
key and the computer is asleep when the job should have run, your job will run when the computer wakes up. However, if the machine is off when the job should have run, the job does not execute until the next designated time occurs.

All other

launchd
jobs are skipped when the computer is turned off or asleep; they will not run until the next designated time occurs.

Consequently, if the computer is always off at the job’s scheduled time, both

cron
jobs and
launchd
jobs never run. For example, if you always turn your computer off at night, a job scheduled to run at 1 A.M. will never be run.

Jul 2, 2013 6:38 PM

Reply Helpful

Jan 4, 2014 3:32 PM in response to JsinJ In response to JsinJ

The original questions was raised quite some time ago … but I do not see any real answer.


We have a similar problem on a 10.8 server machine. The daemon jobs ran perfectly under 10.6.8 … but recently we moved our deployment to 10.8 and now the script runs "more or less" every 4 hours, while it should run every hour (2 minutes after).


@JsinJ … do you have a solution in the meantime?

Jan 4, 2014 3:32 PM

Reply Helpful

Jun 11, 2014 9:33 AM in response to JsinJ In response to JsinJ

I too have been trying to solve this issue. I have a Launchd call a shell script that calls an AppleScript that opens iTunes and plays a sound. We use this to play our company's "bells" to start work, take breaks, etc. I've found that the times can be 10 minutes off. Yikes!


A few more details: Since it runs an AppleScript that calls iTunes, I believe this cannot be a LaunchDeamon - so I have it set up as a /Library/LaunchAgent/com.example.plist -and we have the user always logged in. The server mini that runs this never sleeps, so the discussion on if it is alseep/off just doesn't apply to my situation.

I'd love to know if there is a way to prioritize these jobs or if there is some way to make this more reliable? Any help would be much appreciated!


----

TO: Barney-15E: Your first response says

You can only set one calendar interval.

Just like JsinJ, I have multiple calendar times in one plist using the array:

<key>StartCalendarInterval</key>

<array>

<dict>

<key>Hour</key>

<integer>21</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

<dict>

<key>Hour</key>

<integer>05</integer>

<key>Minute</key>

<integer>0</integer>

</dict>

</array>


Is this the problem?? Would it be more reliable if I made a separate plist per time interval? Not sure if that's what you meant by your reply?


Thanks again for any help.

Jun 11, 2014 9:33 AM

Reply Helpful

Jun 11, 2014 9:52 AM in response to MT Buck In response to MT Buck

Is this the problem?? Would it be more reliable if I made a separate plist per time interval? Not sure if that's what you meant by your reply?


Thanks again for any help.


If they are at least firing at different times, albeit not accurately, I would think that the exact timing has nothing to do with that.


You might try testing the single time per plist optoion, though.

Jun 11, 2014 9:52 AM

Reply Helpful

Jun 12, 2014 9:42 AM in response to JsinJ In response to JsinJ

I tried to separate each time event into its own plist. As Barney-15E thought, didn't change the outcome. However, I did discover this:


I also have a test of this running locally on my MacBook Pro, and the one locally seems to trigger within the same minute on my local machine (which is accurate enough for what I need). At first I thought perhaps the server was prioritizing other processes first, but now I believe it is only because I'm always using my machine (I'm actively using it).


On the Mini Server that I have deployed this on, it is super sporatic with it now being 15 minutes off at times. I've turned off all energy savings, screen savers, etc. - so that it is always on and running. It seems that even though those are all turned off, Launchd notices the lack of activity on the machine and reacts as if it was asleep? If I monitor it using ARD, it won't trigger on time. It seems to trigger eventually, but with no reason as to when and why. Now, if I control the machine with ARD - just moving the mouse... it triggers within the same minute... so far everytime. So, this seems to indicate that Launchd is waiting for some "activity" before it triggers the StartCalendarInterval??

Jun 12, 2014 9:42 AM

Reply Helpful
User profile for user: JsinJ

Question: launchd StartCalendarInterval doesn't run on time