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

[Sidney San Martín]

This daemon needs to check in with a server at predetermined intervals
(say, every hour). In certain situations the server may want to
instruct it to change its checkin interval. I planned to use
StartInterval to launch the daemon as needed to check in.

There's also a client application which connects to a launchd-provided
UNIX domain socket. When the client's connected, the daemon stays
running and StartInterval isn't an issue, but when the client is not
running, I see no reason not to let the daemon time out and exit until
a client tries to connect or until its next checkin.

What do you see here that's dangerous or otherwise a bad design decision?

On Thu, Sep 17, 2009 at 6:07 PM, Nehemiah Dacres <vivacarlie at gmail.com> wrote:
> 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
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
>
>