In the past when I need to diagnose something like this I've used the kill.d script from Brendan Gregg:
dtrace:::BEGIN
{
/* Print header */
printf("%5s %12s %5s %-6s %s\n","FROM","COMMAND","SIG","TO","RESULT");
}
syscall::kill:entry
{
/* Record target PID and signal */
self->target = arg0;
self->signal = arg1;
}
syscall::kill:return
{
/* Print source, target, and result */
printf("%5d %12s %5d %-6d %d\n",
pid,execname,self->signal,self->target,(int)arg0);
/* Cleanup memory */
self->target = 0;
self->signal = 0;
}
Running it and then running killall Finder in another shell results in:
[user@fozzy Scripts]$ sudo kill.d.sh
FROM COMMAND SIG TO RESULT
155 launchd 15 4294900609 -1
66872 killall 15 66687 0
Which tells you what (killall at PID 66872 with Signal 15) killed which process (in this case, 66687 my then-running instance of the Finder) and the result. It does slow down the system somewhat while running, but should provide you with the results you need - just make a note of your Finder PID before hand, and then let it run (either while you are working, or overnight to avoid disrupting your work) and look to see what killed that PID.
To bring the contents of Mateusz's comment here in an answer. Credit to Camelot for the steps.
The AppleScript log statement does not write to the StandardOutPath. Writing to a log file takes 3 steps. The second step may take 2 forms depending of wether you want to save previously written data.
-- Open the log file
set logFile to (open for access POSIX file "/var/tmp/myScript.log" with write permission)
-- Write some data to it (clearing the existing contents)
write "some data" & return to logFile
-- Or, write by appending, some data to the end of existing data
write "some data" & return to logFile starting at eof
-- Close the file
close access logFile
It may help to rewrite the 1st step as 2 statements:
set logFilePath to "/var/tmp/myScript.log"
set logFile to (open for access POSIX file logFilePath with write permission)
I am still searching for an answer regarding the log statements and event log. At this point, I think they go into deep space.
Best Answer
Since Apple publishes the source code for launchd, you might have better luck just attaching a debugger to the process to inspect or set breakpoints.
That and changing the log level might also be overkill. You can inspect the loaded jobs quite easily and disable them / change them to call debugging scripts or even set another job to dump status or log messages when another process starts or stops.
I'd be interested in more specifics of what you are doing - this seems like a great example of an XY problem. You're asking about the solution you see as the best way forward and not about what the actual problem / issue is.