Re: launchd-dev Digest, Vol 27, Issue 5

View: New views

4 Messages — Rating Filter: Alert me

	Re: launchd-dev Digest, Vol 27, Issue 5 by Nehemiah Dacres-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
	Re: launchd-dev Digest, Vol 27, Issue 5 by Sidney San Martín :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@... > http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev > > _______________________________________________ launchd-dev mailing list launchd-dev@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
	Re: launchd-dev Digest, Vol 27, Issue 5 by Sidney San Martín :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message It won't. The daemon manages its timing while running, and would work (with no modifications) with KeepAlive and no OnDemand keys at all. I'd just rather NOT have the daemon idling away all day when launchd has a perfectly good mechanism for launching it periodically. On Fri, Sep 18, 2009 at 1:12 PM, Nehemiah Dacres <vivacarlie@...> wrote: > >> I see no reason not to let the daemon time out and exit until >> a client tries to connect or until its next checkin. >> > > neither do I, but who says the program will start up if its already running? > > > -- > > "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@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
	Re: launchd-dev Digest, Vol 27, Issue 5 by Sidney San Martín :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message How would a WatchPath help the situation? launchd already starts me when something tries to connect to the socket. launchd only reads your plist at startup/login, so changing the StartInterval on disk will do nothing (unless you know something I don't). Currently, if modifying the job in memory isn't possible, I think the best options are to either run all the time and manage timings myself, or to modify the StartInterval on disk and fire up a helper tool to unload/reload my plist (which really should not happen too often). If clients are connected, they'll be booted out for a few seconds and reconnect themselves. No big loss. On Fri, Sep 18, 2009 at 2:48 PM, Nehemiah Dacres <vivacarlie@...> wrote: > so you want the ability to connect to it ALL the time but dont want it > running All the time. note that a waiting process doesn't take that much > proessor time if its not doing anything but listening to a socket but if you > must you can have the client program modify a file on a path and set the > server's launchd.plist for "WatchPaths" to start the daemon when said path > is altered. > I guess you can change startInterval or IdleTime from the program, the test > (which I may not perform later) is if the start interval will be changed if > the file is not reloaded unto launchd after altering. I would say > > On Fri, Sep 18, 2009 at 1:12 PM, Sidney San Martín <s@...> wrote: >> >> It won't. The daemon manages its timing while running, and would work >> (with no modifications) with KeepAlive and no OnDemand keys at all. >> I'd just rather NOT have the daemon idling away all day when launchd >> has a perfectly good mechanism for launching it periodically. >> >> On Fri, Sep 18, 2009 at 1:12 PM, Nehemiah Dacres <vivacarlie@...> >> wrote: >> > >> >> I see no reason not to let the daemon time out and exit until >> >> a client tries to connect or until its next checkin. >> >> >> > >> > neither do I, but who says the program will start up if its already >> > running? >> > >> > >> > -- >> > >> > "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 >> > > > > > -- > > "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@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

	Re: launchd-dev Digest, Vol 27, Issue 5 by Nehemiah Dacres-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
	Re: launchd-dev Digest, Vol 27, Issue 5 by Sidney San Martín :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@... > http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev > > _______________________________________________ launchd-dev mailing list launchd-dev@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
	Re: launchd-dev Digest, Vol 27, Issue 5 by Sidney San Martín :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message It won't. The daemon manages its timing while running, and would work (with no modifications) with KeepAlive and no OnDemand keys at all. I'd just rather NOT have the daemon idling away all day when launchd has a perfectly good mechanism for launching it periodically. On Fri, Sep 18, 2009 at 1:12 PM, Nehemiah Dacres <vivacarlie@...> wrote: > >> I see no reason not to let the daemon time out and exit until >> a client tries to connect or until its next checkin. >> > > neither do I, but who says the program will start up if its already running? > > > -- > > "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@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
	Re: launchd-dev Digest, Vol 27, Issue 5 by Sidney San Martín :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message How would a WatchPath help the situation? launchd already starts me when something tries to connect to the socket. launchd only reads your plist at startup/login, so changing the StartInterval on disk will do nothing (unless you know something I don't). Currently, if modifying the job in memory isn't possible, I think the best options are to either run all the time and manage timings myself, or to modify the StartInterval on disk and fire up a helper tool to unload/reload my plist (which really should not happen too often). If clients are connected, they'll be booted out for a few seconds and reconnect themselves. No big loss. On Fri, Sep 18, 2009 at 2:48 PM, Nehemiah Dacres <vivacarlie@...> wrote: > so you want the ability to connect to it ALL the time but dont want it > running All the time. note that a waiting process doesn't take that much > proessor time if its not doing anything but listening to a socket but if you > must you can have the client program modify a file on a path and set the > server's launchd.plist for "WatchPaths" to start the daemon when said path > is altered. > I guess you can change startInterval or IdleTime from the program, the test > (which I may not perform later) is if the start interval will be changed if > the file is not reloaded unto launchd after altering. I would say > > On Fri, Sep 18, 2009 at 1:12 PM, Sidney San Martín <s@...> wrote: >> >> It won't. The daemon manages its timing while running, and would work >> (with no modifications) with KeepAlive and no OnDemand keys at all. >> I'd just rather NOT have the daemon idling away all day when launchd >> has a perfectly good mechanism for launching it periodically. >> >> On Fri, Sep 18, 2009 at 1:12 PM, Nehemiah Dacres <vivacarlie@...> >> wrote: >> > >> >> I see no reason not to let the daemon time out and exit until >> >> a client tries to connect or until its next checkin. >> >> >> > >> > neither do I, but who says the program will start up if its already >> > running? >> > >> > >> > -- >> > >> > "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 >> > > > > > -- > > "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@... http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev