Launchd and starting a job every day - does "StartCalendarInterval" work?

Hi all,

BUT - it works if I specify the minutes figure only! If I try to run the very same script with the very same plist file but with the hour it will NOT work.

If I remember correctly, I have experienced the following symptom when I was testing StartCalendarInterval.

If the scheduled time is, say 14:05, and if you run 'launchctl load ..' at 14:00, then it can happen that the job is not executed, at least today; it may (or may not) be executed tomorrow, I guess.

Please try running 'launchctl load ..' at least 1 (or 2?) hours earlier than the scheduled time of the job.

PowerMac G4 Mac OS X (10.4.3)

Hi Jason,

Could it be because of the defective way launchd runs?
(See my summary about how you can't rely on a regular Periodic maintenance)

My idea is that it would work if only your computer was NEVER restarted and NEVER sleeping...

I'm subscribing to your thread: curious to learn more about launchd!
Axl

Hi Jason,
Of course AxL is correct about problems related to sleeping but that doesn't apply to you. Launchd was broken before Mac OS X 10.4.3 as you've read. A bug caused the jobs to run only once and not again after that. However as you point out, that has been fixed. As you have observed, the periodic scripts are run. There is nothing special about them; they run like any script would. Just to make sure, I just created and tested one and they still work. It's StartInterval and I believe WatchPaths that aren't working. At least I can't get WatchPaths to work when the path is a file.

You haven't given us any information with which to figure out what's wrong in your case. You know that the periodic scripts run; how is your job different from the periodic ones?

One mistake made by many people that write cron-type scripts for the first time is to assume that the environment of the script is the same as if the script is run in the shell. The PATH in the script's environment is /usr/bin:/bin:/usr/sbin:/sbin, which is minimal. You should change the script to use absolute paths when invoking all executables. The current working directory is the root of the hard drive, '/' and there is no $HOME directory. I recommend that when you get it working, your first experiment should be to dump the environment so you can study it.

You mention logging. Launchd doesn't log anything by default to my knowledge. If you want to log something, you must invoke syslog yourself. You can also output information to a text file, as I did to get the above information about the environment. Again, remember to use absolute paths.
--
Gary
~~~~
It has just been discovered that research causes cancer
in rats.

Hi Jason,

> Any ideas?

Yes, remove the space between "#!" and "/bin/bash" in the "she-bang" line (first line) of your shell script.
--
Gary
~~~~
It's a small world, but I wouldn't want to have to paint it.
-- Steven Wright

Hi Jason,
I think you've hit the nail on the head; we're past the full moon so naturally it doesn't work. Here's an important test. Does the script work when you invoke it from the command line?
--
Gary
~~~~
Rich bachelors should be heavily taxed. It is not
fair that some men should be happier than others.
-- Oscar Wilde

Hi Jason,
I'd be happy to post it. I didn't before because I did pretty much what you did. I actually had it laying around from a test of the environment. I wanted to see what effect the "UserName" key had on the environment. The shell script itself had been a test of the environment of a LoginHook. I did essentially what you did; I copied one of Apple's property lists and made minor changes. I named the property list org.dyndns.Username.plist and put it in the /System/Library/LaunchDaemons directory. Its permissions are 644 and I didn't even change the owner to root. All that seemed to matter was that root could read it. Here's the property list

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>org.dyndns.Username</string>
<key>ProgramArguments</key>
<array>
<string>/Users/kerbaugh/Library/init/loginwindow/loginhook.sh</string>
</array>
<key>UserName</key>
<string>kerbaugh</string>
<key>StartCalendarInterval</key>
<dict>
<!--<key>Hour</key>-->
<!--<integer>18</integer>-->
<key>Minute</key>
<integer>46</integer>
</dict>
</dict>
</plist>

You might check to see that the line endings on the file are UNIX line endings but I'm not sure that matters in XML. I commented out the hour key but it worked before with it. Obviously, you don't need the UserName key; I just didn't remove it from the test. I know that's not the issue. One thing, don't copy-and-paste mine as the indention is produced with non-breaking spaces which probably will break XML. If you do copy-and-paste, just replace them with regular spaces or tabs.

The script just dumps a few environment variables into a file, much like yours.

#!/bin/bash
touch loginrecord.txt
echo "The new value of \$( pwd ) is: "$( pwd ) >> loginrecord.txt
echo "The value of \$PWD is: "$PWD >> loginrecord.txt
echo "The value of \$UID is: "$UID >> loginrecord.txt
echo "The value of \$HOME is: "$HOME >> loginrecord.txt
echo "The value of \$PATH is: "$PATH >> loginrecord.txt
echo "The value of \$1 is: "$1 >> loginrecord.txt
echo "past first launchctl" >> loginrecord.txt
/bin/launchctl list >> loginrecord.txt

The permissions are 755 and the path is in the property list.

I'm sure you didn't do anything stupid, just subtly wrong and maybe even careless. However, it's hardly obvious to me and I've done this several times. Oh, what's the name of your property list?
--
Gary
~~~~
When a place gets crowded enough to require ID's, social
collapse is not far away. It is time to go elsewhere. The
best thing about space travel is that it made it possible to
go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"

Hi Jason,
No, I just put it in my ~/Library/LaunchAgents directory, changed the minutes key to 19 and loaded it. It ran, although at about 20 after. I didn't logout and log back in; I just loaded it with:

launchctl load ~/Library/LaunchAgents/org.dyndns.Username.plist

Invoking launchctl without using sudo puts the job in the user's job list. You might try running "launchctl list" to make sure yours loaded. By the way, with what app did you edit your property list?
--
Gary
~~~~
"Contrariwise," continued Tweedledee, "if it was so, it
might be, and if it were so, it would be; but as it isn't,
it ain't. That's logic!"
-- Lewis Carroll, "Through the Looking Glass"