Working with overrides.plist

[Dean Shavit]

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).


_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Edward R. Marczak]

On Thu, Sep 3, 2009 at 11:01 AM, Dean
Shavit<acn-lists-dean@...> 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@...
w: http://www.radiotope.com/writing
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Dean Shavit]

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@...> 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@...
> w: http://www.radiotope.com/writing
> _______________________________________________
> 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

[Damien Sorresso]

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.



_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Dean Shavit]

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.
>

_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Damien Sorresso]

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.



_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Damien Sorresso]

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.



_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Damien Sorresso]

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.



_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Dean Shavit]

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.
>

_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev