Working with overrides.plist
Kudos to the launchd team for finding a way of allowing a sysadmin to disable / enable a launchagent in /Library and the new by-uidNumber settings for launchagents on a per user basis. That solves a few issues for me. However, other than having to programmatically manipulate the overrides.plist, is there a sanctioned command to do so? I've noted of course that launchctl -w doesn't do it (as the man page states).
On Thu, Sep 3, 2009 at 11:01 AM, Dean Shavit<acn-lists-dean@macworkshops.com> wrote:
I've noted of course that launchctl -w doesn't do it (as the man page states).
launchctl *does* do it - what it doesn't do is modify the plist. Instead, it updates the override file. launchd does still respect the disabled key in a plist, though. (For example, to disable a launchd job machine-wide). -- Ed Marczak e: marczak@radiotope.com w: http://www.radiotope.com/writing
OK, I think I figured it out. Here's what I found: so if you're going to be using the override for a launchagent with specified SessionTypes, you need to specify a different session type - so: sudo launchctl unload -w -S LoginWindow /Library/LaunchAgents/ com.most.vnc.plist That sets Disabled to true in the overrides.plist However, in Leopard, launchctl allowed specifying *any* sessiontype in the plist to write the Disabled key so: sudo launchctl unload -w -S Aqua /Library/LaunchAgents/ com.most.vnc.plist had the same result. However, in Snow Leopard, it generates an error. This change was not documented, as far as I can tell. Does anyone think this requires a bug report? Thanks again for the pointer Ed. On Sep 3, 2009, at 11:24 AM, Edward Marczak wrote:
On Thu, Sep 3, 2009 at 11:01 AM, Dean Shavit<acn-lists-dean@macworkshops.com> wrote:
I've noted of course that launchctl -w doesn't do it (as the man page states).
launchctl *does* do it - what it doesn't do is modify the plist. Instead, it updates the override file.
launchd does still respect the disabled key in a plist, though. (For example, to disable a launchd job machine-wide). -- Ed Marczak e: marczak@radiotope.com w: http://www.radiotope.com/writing _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
On Sep 3, 2009, at 9:53 AM, Dean Shavit wrote:
OK,
I think I figured it out.
Here's what I found:
so if you're going to be using the override for a launchagent with specified SessionTypes, you need to specify a different session type - so:
sudo launchctl unload -w -S LoginWindow /Library/LaunchAgents/ com.most.vnc.plist
That sets Disabled to true in the overrides.plist
However, in Leopard, launchctl allowed specifying *any* sessiontype in the plist to write the Disabled key
so:
sudo launchctl unload -w -S Aqua /Library/LaunchAgents/ com.most.vnc.plist
had the same result. However, in Snow Leopard, it generates an error. This change was not documented, as far as I can tell. Does anyone think this requires a bug report?
You must specify a session when you manipulate any job which has the LimitLoadToSessionType property set. If the session type you specify isn't one of the elements in LimitLoadToSession type, then launchctl won't do anything. There is nothing tying modifying the overrides database to the session type you specify. If you've noticed a pattern, it's a result of the underlying implementation. -- Damien Sorresso BSD Engineering Apple Inc.
On Sep 3, 2009, at 12:30 PM, Damien Sorresso wrote:
On Sep 3, 2009, at 9:53 AM, Dean Shavit wrote:
OK,
I think I figured it out.
Here's what I found:
so if you're going to be using the override for a launchagent with specified SessionTypes, you need to specify a different session type - so:
sudo launchctl unload -w -S LoginWindow /Library/LaunchAgents/ com.most.vnc.plist
That sets Disabled to true in the overrides.plist
However, in Leopard, launchctl allowed specifying *any* sessiontype in the plist to write the Disabled key
so:
sudo launchctl unload -w -S Aqua /Library/LaunchAgents/ com.most.vnc.plist
had the same result. However, in Snow Leopard, it generates an error. This change was not documented, as far as I can tell. Does anyone think this requires a bug report?
You must specify a session when you manipulate any job which has the LimitLoadToSessionType property set. If the session type you specify isn't one of the elements in LimitLoadToSession type, then launchctl won't do anything.
I am aware of that. But there's differences in behavior. In Leopard, specifying any Session Type listed in the LaunchAgent using "sudo" worked to write the Disable key in the plist targeted. In Snow Leopard, this behavior does not hold true for the overrides.plist
There is nothing tying modifying the overrides database to the session type you specify.
OK, but evidently the Session Type specified has an impact on whether the launchctl command can successfully modify overrides.plist!
If you've noticed a pattern, it's a result of the underlying implementation.
I suppose, but I would've hoped for some documentation in that area. I guess a bug report is a bit late. Hope this helps someone else.
-- Damien Sorresso BSD Engineering Apple Inc.
On Sep 3, 2009, at 10:37 AM, Dean Shavit wrote:
I am aware of that. But there's differences in behavior. In Leopard, specifying any Session Type listed in the LaunchAgent using "sudo" worked to write the Disable key in the plist targeted. In Snow Leopard, this behavior does not hold true for the overrides.plist
I'd argue that the Leopard behavior was improper. Asking to modify a job in a session where it cannot exist should be a no-op. In any case, we really hope to clean up the mess of sessions post-Snow Leopard. We also just want to get rid of the Disabled key entirely. -- Damien Sorresso BSD Engineering Apple Inc.
On Sep 3, 2009, at 11:02 AM, Damien Sorresso wrote:
On Sep 3, 2009, at 10:37 AM, Dean Shavit wrote:
I am aware of that. But there's differences in behavior. In Leopard, specifying any Session Type listed in the LaunchAgent using "sudo" worked to write the Disable key in the plist targeted. In Snow Leopard, this behavior does not hold true for the overrides.plist
I'd argue that the Leopard behavior was improper. Asking to modify a job in a session where it cannot exist should be a no-op.
In any case, we really hope to clean up the mess of sessions post- Snow Leopard. We also just want to get rid of the Disabled key entirely.
Well, not get rid of it, but we certainly want to change the behavior behind it. So we may keep the name of the key, but it would act differently. -- Damien Sorresso BSD Engineering Apple Inc.
On Sep 3, 2009, at 1:02 PM, Damien Sorresso wrote:
On Sep 3, 2009, at 10:37 AM, Dean Shavit wrote:
I am aware of that. But there's differences in behavior. In Leopard, specifying any Session Type listed in the LaunchAgent using "sudo" worked to write the Disable key in the plist targeted. In Snow Leopard, this behavior does not hold true for the overrides.plist
I'd argue that the Leopard behavior was improper. Asking to modify a job in a session where it cannot exist should be a no-op.
Agreed that the Leopard behavior was improper. However, since the "proper" behavior was not documented, and still isn't, I would argue that the launchctl man page needs some concrete examples and explanation of the proper behavior - it is really thin, and apropos shows no mention of "overrides.plist" anyway. My LaunchAgent contains *two* Session Types - Aqua and LoginWindow, just like com.apple.RemoteDesktop.plist If the "correct" behavior is to limit the unload/load behavior to "active" or "existable" Session Types, you should say so in the man page. Since it worked in Leopard, I made the incorrect assumption it would carry over to Snow Leopard. If you wish, I will *volunteer* to expand the man page with some more examples for the next release of Mac OS X. Just send me the NDA, and I'm your man-scribe for the next two years....
In any case, we really hope to clean up the mess of sessions post- Snow Leopard. We also just want to get rid of the Disabled key entirely.
OK, go ahead, get rid of the key, but please leave some sort of mechanism for sysadmins or developers to disable a LaunchAgent via an override mechanism so long as they can sudo as root. I also personally feel that once the override is applied, no logout should be required to unload a currently running instance of the LaunchAgent in quesiton - the override should automatically unload the LaunchAgent for currently logged in users and terminate any processes they've spawned. As it is, we have a lot of manual cleanup to do if we want to stop one without a logout. Also, while we're on the subject of post-Snow Leopard, please consider implementing group, user, and computer-level management of LaunchAgents via MCX.
-- Damien Sorresso BSD Engineering Apple Inc.
On Sep 3, 2009, at 10:37 AM, Dean Shavit wrote:
On Sep 3, 2009, at 12:30 PM, Damien Sorresso wrote:
On Sep 3, 2009, at 9:53 AM, Dean Shavit wrote:
OK,
I think I figured it out.
Here's what I found:
so if you're going to be using the override for a launchagent with specified SessionTypes, you need to specify a different session type - so:
sudo launchctl unload -w -S LoginWindow /Library/LaunchAgents/ com.most.vnc.plist
That sets Disabled to true in the overrides.plist
However, in Leopard, launchctl allowed specifying *any* sessiontype in the plist to write the Disabled key
so:
sudo launchctl unload -w -S Aqua /Library/LaunchAgents/ com.most.vnc.plist
had the same result. However, in Snow Leopard, it generates an error. This change was not documented, as far as I can tell. Does anyone think this requires a bug report?
You must specify a session when you manipulate any job which has the LimitLoadToSessionType property set. If the session type you specify isn't one of the elements in LimitLoadToSession type, then launchctl won't do anything.
I am aware of that. But there's differences in behavior. In Leopard, specifying any Session Type listed in the LaunchAgent using "sudo" worked to write the Disable key in the plist targeted. In Snow Leopard, this behavior does not hold true for the overrides.plist
There is nothing tying modifying the overrides database to the session type you specify.
OK, but evidently the Session Type specified has an impact on whether the launchctl command can successfully modify overrides.plist!
If you've noticed a pattern, it's a result of the underlying implementation.
I suppose, but I would've hoped for some documentation in that area. I guess a bug report is a bit late. Hope this helps someone else.
I misread your previous email. Are you saying that, for a job that is LimitLoadToSessionType { LoginWindow }, you must specify a non- LoginWindow session to disable or enable it? If so, this sounds like bad behavior, and you should file a bug. -- Damien Sorresso BSD Engineering Apple Inc.
participants (3)
-
Damien Sorresso
-
Dean Shavit
-
Edward Marczak