[launchd-dev] launchd-dev Digest, Vol 27, Issue 5

[Nehemiah Dacres]

That's very dangerous.

>
> How can I modify properties of a job (StartInterval, in this case)

without un/reloading it from launchd?


when I read "how do i modify x without reloading it" I see a design issue.
Startinverval " When an agent has the StartInterval key in its .plist file,
so that it is run every *N* seconds"
from macgeekery .

which is a summary of the launchd manual

*StartInterval* *<integer>*
     This optional key causes the job to be started every N seconds.
If the system is asleep, the job will
     be started the next time the computer wakes up.  If multiple
intervals transpire before the computer is
     woken, those events will be coalesced into one event upon wake from sleep.

Ideally, I want a daemon to be
> able to modify its own StartInterval while running, so that it applies
> the next time the daemon idles out, and without disrupting any of its
> launchd-provided sockets.
>
> Idleingout, I think referes to OnDemand, because you want to control when
the job comes back after being stopped from lack of use? This is probibly
not necessary.
again from the man page

 *KeepAlive* *<boolean* *or* *dictionary* *of* *stuff>*
     This optional key is used to control whether your job is to be
kept continuously running or to let
     demand and conditions control the invocation. The default is
false and therefore only demand will start
     the job. The value may be set to true to unconditionally keep the
job alive. Alternatively, a dictio-nary dictionary
     nary of conditions may be specified to selectively control
whether *launchd* keeps a job alive or not. If
     multiple keys are provided, launchd ORs them, thus providing
maximum flexibility to the job to refine
     the logic and stall if necessary. If *launchd* finds no reason to
restart the job, it falls back on
     demand based invocation.  Jobs that exit quickly and frequently
when configured to be kept alive will
     be throttled to converve system resources.

           *SuccessfulExit* *<boolean>*
           If true, the job will be restarted as long as the program
exits and with an exit status of zero.
           If false, the job will be restarted in the inverse
condition.  This key implies that "RunAtLoad"
           is set to true, since the job needs to run at least once
before we can get an exit status.

           *NetworkState* *<boolean>*
           If true, the job will be kept alive as long as the network
is up, where up is defined as at least
           one non-loopback interface being up and having IPv4 or IPv6
addresses assigned to them.  If
           false, the job will be kept alive in the inverse condition.

           *PathState* *<dictionary* *of* *booleans>*
           Each key in this dictionary is a file-system path. If the
value of the key is true, then the job
           will be kept alive as long as the path exists.  If false,
the job will be kept alive in the
           inverse condition. The intent of this feature is that two
or more jobs may create semaphores in
           the file-system namespace.

           *OtherJobEnabled* *<dictionary* *of* *booleans>*
           Each key in this dictionary is the label of another job. If
the value of the key is true, then
           this job is kept alive as long as that other job is
enabled. Otherwise, if the value is false,
           then this job is kept alive as long as the other job is
disabled.  This feature should not be
           considered a substitute for the use of IPC.

 Tell us why you want to do that and I could probibly give you a better
design decision.





-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/launchd-dev/attachments/20090917/f43dec14/attachment.html>