From jkneer at n8geil.de  Thu Nov  1 15:44:20 2007
From: jkneer at n8geil.de (Johannes Kneer)
Date: Thu Nov  1 15:43:43 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
Message-ID: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>

Hi

My problem boils down to porting this xinetd file to launchd:

# default: off
# description: Bitlbee is an IRC gateway to other networks.
service ircd
{
         type            = UNLISTED
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= bitlbee
         group           = nogroup
	server		= /sw/sbin/bitlbee
         port            = 6667
	disable		= no
         log_on_failure  += USERID
}

So this is what I have come up with:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>org.bitlbee.bitlbee</string>
	<key>OnDemand</key>
	<true/>
	<key>ProgramArguments</key>
	<array>
		<string>/sw/sbin/bitlbee</string>
	</array>
	<key>ServiceDescription</key>
	<string>bitlbee irc-im proxy</string>
	<key>Sockets</key>
	<dict>
		<key>Listener</key>
		<dict>
			<key>SockFamily</key>
			<string>IPv4</string>
			<key>SockProtocol</key>
			<string>TCP</string>
			<key>SockServiceName</key>
			<string>6667</string>
			<key>SockType</key>
			<string>stream</string>
		</dict>
	</dict>
	<key>inetdCompatibility</key>
	<dict>
		<key>Wait</key>
		<false/>
	</dict>
	<key>UserName</key>
	<string>bitlbee</string>
</dict>
</plist>



And well it does not work. When I try to load (launchctl load  
thisfile.plist) I always get a "bind(): Operation not permitted" error  
and I can't connect to the server.
And how would I restrict the service to localhost only?

I guess I'm missing something. I'd just like to have bitlbee working  
in leopard. Would apreciate some help.

Johannes

From zarzycki at apple.com  Thu Nov  1 16:02:22 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov  1 16:01:37 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
Message-ID: <F307520B-11B6-453C-BE38-52D318588964@apple.com>

Are you making sure to run launchctl as root?

Once you do, is the job already loaded? Check like so: sudo launchctl  
list | grep org.bitlbee.bitlbee

Also, please remove the KeepAlive key/value pair. It is incompatible  
with the rest of the plist. I suppose we should add a sanity check for  
that... Oh well.

Cheers,


davez

On Nov 1, 2007, at 3:44 PM, Johannes Kneer wrote:

> Hi
>
> My problem boils down to porting this xinetd file to launchd:
>
> # default: off
> # description: Bitlbee is an IRC gateway to other networks.
> service ircd
> {
>        type            = UNLISTED
> 	socket_type	= stream
> 	protocol	= tcp
> 	wait		= no
> 	user		= bitlbee
>        group           = nogroup
> 	server		= /sw/sbin/bitlbee
>        port            = 6667
> 	disable		= no
>        log_on_failure  += USERID
> }
>
> So this is what I have come up with:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
> ">
> <plist version="1.0">
> <dict>
> 	<key>KeepAlive</key>
> 	<true/>
> 	<key>Label</key>
> 	<string>org.bitlbee.bitlbee</string>
> 	<key>OnDemand</key>
> 	<true/>
> 	<key>ProgramArguments</key>
> 	<array>
> 		<string>/sw/sbin/bitlbee</string>
> 	</array>
> 	<key>ServiceDescription</key>
> 	<string>bitlbee irc-im proxy</string>
> 	<key>Sockets</key>
> 	<dict>
> 		<key>Listener</key>
> 		<dict>
> 			<key>SockFamily</key>
> 			<string>IPv4</string>
> 			<key>SockProtocol</key>
> 			<string>TCP</string>
> 			<key>SockServiceName</key>
> 			<string>6667</string>
> 			<key>SockType</key>
> 			<string>stream</string>
> 		</dict>
> 	</dict>
> 	<key>inetdCompatibility</key>
> 	<dict>
> 		<key>Wait</key>
> 		<false/>
> 	</dict>
> 	<key>UserName</key>
> 	<string>bitlbee</string>
> </dict>
> </plist>
>
>
>
> And well it does not work. When I try to load (launchctl load  
> thisfile.plist) I always get a "bind(): Operation not permitted"  
> error and I can't connect to the server.
> And how would I restrict the service to localhost only?
>
> I guess I'm missing something. I'd just like to have bitlbee working  
> in leopard. Would apreciate some help.
>
> Johannes
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From jkneer at n8geil.de  Thu Nov  1 16:47:01 2007
From: jkneer at n8geil.de (Johannes Kneer)
Date: Thu Nov  1 16:46:26 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <F307520B-11B6-453C-BE38-52D318588964@apple.com>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
	<F307520B-11B6-453C-BE38-52D318588964@apple.com>
Message-ID: <13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>

Hi

> Are you making sure to run launchctl as root?
> Once you do, is the job already loaded? Check like so: sudo  
> launchctl list | grep org.bitlbee.bitlbee

host:~ root# launchctl unload /Library/LaunchDaemons/ 
org.bitlbee.bitlbee.plist
host:~ root# vim /Library/LaunchDaemons/org.bitlbee.bitlbee.plist
*host:~ root# launchctl load /Library/LaunchDaemons/ 
org.bitlbee.bitlbee.plist
bind(): Operation not permitted
host:~ root# launchctl list | grep org.bitlbee.bitlbee
-	0	org.bitlbee.bitlbee
host:~ root# telnet 127.0.0.1 6667
Trying 127.0.0.1...
host: connect to address 127.0.0.1: Connection refused
host: Unable to connect to remote host
host:~ root#

(I like ssh root@localhost more than sudo :)

> Also, please remove the KeepAlive key/value pair. It is incompatible  
> with the rest of the plist. I suppose we should add a sanity check  
> for that... Oh well.

The above took place with the removed KeepAlive key/value pair.
And I guess a sanity check is a good idea... I'm wondering about the  
low traffic here on the list. Launchd is now a central column of the  
OS X experience - and no more developers have questions about it?


cheers,
Johannes

>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
>> ">
>> <plist version="1.0">
>> <dict>
>> 	<key>Label</key>
>> 	<string>org.bitlbee.bitlbee</string>
>> 	<key>OnDemand</key>
>> 	<true/>
>> 	<key>ProgramArguments</key>
>> 	<array>
>> 		<string>/sw/sbin/bitlbee</string>
>> 	</array>
>> 	<key>ServiceDescription</key>
>> 	<string>bitlbee irc-im proxy</string>
>> 	<key>Sockets</key>
>> 	<dict>
>> 		<key>Listener</key>
>> 		<dict>
>> 			<key>SockFamily</key>
>> 			<string>IPv4</string>
>> 			<key>SockProtocol</key>
>> 			<string>TCP</string>
>> 			<key>SockServiceName</key>
>> 			<string>6667</string>
>> 			<key>SockType</key>
>> 			<string>stream</string>
>> 		</dict>
>> 	</dict>
>> 	<key>inetdCompatibility</key>
>> 	<dict>
>> 		<key>Wait</key>
>> 		<false/>
>> 	</dict>
>> 	<key>UserName</key>
>> 	<string>bitlbee</string>
>> </dict>
>> </plist>
>>
>>
From zarzycki at apple.com  Thu Nov  1 16:52:59 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov  1 16:52:14 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
	<F307520B-11B6-453C-BE38-52D318588964@apple.com>
	<13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
Message-ID: <65427801-906D-4944-95F2-E2E8B665E952@apple.com>

On Nov 1, 2007, at 4:47 PM, Johannes Kneer wrote:

> Hi
>
>> Are you making sure to run launchctl as root?
>> Once you do, is the job already loaded? Check like so: sudo  
>> launchctl list | grep org.bitlbee.bitlbee
>
> host:~ root# launchctl unload /Library/LaunchDaemons/ 
> org.bitlbee.bitlbee.plist
> host:~ root# vim /Library/LaunchDaemons/org.bitlbee.bitlbee.plist
> *host:~ root# launchctl load /Library/LaunchDaemons/ 
> org.bitlbee.bitlbee.plist
> bind(): Operation not permitted
> host:~ root# launchctl list | grep org.bitlbee.bitlbee
> -	0	org.bitlbee.bitlbee
> host:~ root# telnet 127.0.0.1 6667
> Trying 127.0.0.1...
> host: connect to address 127.0.0.1: Connection refused
> host: Unable to connect to remote host
> host:~ root#
>
> (I like ssh root@localhost more than sudo :)

Odd.

What does the output of "lsof -P | grep 6667" say?

Do you have any firewall magic installed or configured? Is a pre- 
existing copy of the daemon already running?

The bind() error means this is more of a networking problem than a  
launchd problem...


>
>
>> Also, please remove the KeepAlive key/value pair. It is  
>> incompatible with the rest of the plist. I suppose we should add a  
>> sanity check for that... Oh well.
>
> The above took place with the removed KeepAlive key/value pair.
> And I guess a sanity check is a good idea... I'm wondering about the  
> low traffic here on the list. Launchd is now a central column of the  
> OS X experience - and no more developers have questions about it?

I guess developers are either content, or not using it. :-P

davez
From jkneer at n8geil.de  Thu Nov  1 18:21:31 2007
From: jkneer at n8geil.de (Johannes Kneer)
Date: Thu Nov  1 18:20:55 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <65427801-906D-4944-95F2-E2E8B665E952@apple.com>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
	<F307520B-11B6-453C-BE38-52D318588964@apple.com>
	<13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
	<65427801-906D-4944-95F2-E2E8B665E952@apple.com>
Message-ID: <0DAF6FAF-BF2A-4496-B4C9-67D49BFC76B5@n8geil.de>


On 02.11.2007, at 00:52, Dave Zarzycki wrote:

> On Nov 1, 2007, at 4:47 PM, Johannes Kneer wrote:
>
>> Hi
>>
>>> Are you making sure to run launchctl as root?
>>> Once you do, is the job already loaded? Check like so: sudo  
>>> launchctl list | grep org.bitlbee.bitlbee
>>
>> host:~ root# launchctl unload /Library/LaunchDaemons/ 
>> org.bitlbee.bitlbee.plist
>> host:~ root# vim /Library/LaunchDaemons/org.bitlbee.bitlbee.plist
>> *host:~ root# launchctl load /Library/LaunchDaemons/ 
>> org.bitlbee.bitlbee.plist
>> bind(): Operation not permitted
>> host:~ root# launchctl list | grep org.bitlbee.bitlbee
>> -	0	org.bitlbee.bitlbee
>> host:~ root# telnet 127.0.0.1 6667
>> Trying 127.0.0.1...
>> host: connect to address 127.0.0.1: Connection refused
>> host: Unable to connect to remote host
>> host:~ root#
>>
>> (I like ssh root@localhost more than sudo :)
>
> Odd.
>
> What does the output of "lsof -P | grep 6667" say?

host:~ root# lsof -P | grep 6667
host:~ root# launchctl list | grep org.bitlbee.bitlbee
-	0	org.bitlbee.bitlbee
host:~ root# lsof -P | grep 6667
host:~ root#


>
>
> Do you have any firewall magic installed or configured? Is a pre- 
> existing copy of the daemon already running?
>
I have! The build in one was on "set access for specific services and  
applications". But that's all, no ipfw stuff.
If I turn it of, or if I put bitlbee manually in the list of allowed  
apps I can connect to it. BUT why am I not asked whether or not to  
allow the connection in the GUI? This feels like a GUI bug to me.

But it works now. Thank you.

> The bind() error means this is more of a networking problem than a  
> launchd problem...
>
>

Cheers,
Johannes

From kilian_s at gmx.de  Fri Nov  2 05:41:40 2007
From: kilian_s at gmx.de (kilian_s@gmx.de)
Date: Fri Nov  2 05:40:52 2007
Subject: [launchd-dev] Disabled in com.apple.periodic-daily.plist
In-Reply-To: <B68BF967-3FA7-4738-BF55-144C1290B574@apple.com>
References: <13462465.post@talk.nabble.com>
	<B68BF967-3FA7-4738-BF55-144C1290B574@apple.com>
Message-ID: <212B32E7-0C3F-4CF0-8796-8423DC8D4FF3@gmx.de>

Hi,

sorry I was confused by using some GUI editor for lauchd plist files.

Am 29.10.2007 um 08:23 schrieb Kevin Van Vechten:

> On Oct 29, 2007, at 12:09 AM, ksprotte wrote:
>
>> I have seen a lot of talk about using launchd to run the periodic  
>> jobs.
>> However, I could not find a comment about the Disabled flag. It seems
>> that in the com.apple.periodic-daily.plist the Disabled flag is  
>> true by
>> default.
>
> com.apple.periodic-daily.plist does not contain the Disabled key on  
> my Leopard system.  Which system (`sw_vers -buildVersion`) are you  
> seeing this on?
>

In fact my file contains:

	<key>Disabled</key>
	<false/>

I still have the impression that the periodic jobs are not executed -  
I am talking about not having my machine switched on over night. But  
I think I might still expect these jobs to be done, when I switch it  
on...

Best,
   Kilian
From zarzycki at apple.com  Fri Nov  2 06:48:09 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Fri Nov  2 06:47:20 2007
Subject: [launchd-dev] Disabled in com.apple.periodic-daily.plist
In-Reply-To: <212B32E7-0C3F-4CF0-8796-8423DC8D4FF3@gmx.de>
References: <13462465.post@talk.nabble.com>
	<B68BF967-3FA7-4738-BF55-144C1290B574@apple.com>
	<212B32E7-0C3F-4CF0-8796-8423DC8D4FF3@gmx.de>
Message-ID: <BD5E527F-1516-4286-AECF-295C385B9BB3@apple.com>

On Nov 2, 2007, at 5:41 AM, kilian_s@gmx.de wrote:

> Hi,
>
> sorry I was confused by using some GUI editor for lauchd plist files.
>
> Am 29.10.2007 um 08:23 schrieb Kevin Van Vechten:
>
>> On Oct 29, 2007, at 12:09 AM, ksprotte wrote:
>>
>>> I have seen a lot of talk about using launchd to run the periodic  
>>> jobs.
>>> However, I could not find a comment about the Disabled flag. It  
>>> seems
>>> that in the com.apple.periodic-daily.plist the Disabled flag is  
>>> true by
>>> default.
>>
>> com.apple.periodic-daily.plist does not contain the Disabled key on  
>> my Leopard system.  Which system (`sw_vers -buildVersion`) are you  
>> seeing this on?
>>
>
> In fact my file contains:
>
> 	<key>Disabled</key>
> 	<false/>
>
> I still have the impression that the periodic jobs are not executed  
> - I am talking about not having my machine switched on over night.  
> But I think I might still expect these jobs to be done, when I  
> switch it on...

Power on? Or wake from sleep?

If it is the former, we are aware of that bug, and we hope to (but  
cannot promise to) fix it in release after Leopard.

davez
From JJacobs at Motorola.com  Fri Nov  2 09:51:51 2007
From: JJacobs at Motorola.com (Jacobs Joseph-MRG836)
Date: Fri Nov  2 09:51:12 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de><F307520B-11B6-453C-BE38-52D318588964@apple.com><13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
	<65427801-906D-4944-95F2-E2E8B665E952@apple.com>
Message-ID: <83EB8CF7119A7C47A6425E352065A72B024F443A@ct11exm64.ds.mot.com>


>I guess developers are either content, or not using it. :-P

	Well, in our case, our questions centered around the functioning of launchd in Leopard specifically, so this public list was not an appropriate place and we took them directly to Apple.

Joseph Jacobs
Motorola, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071102/faa715e7/attachment-0001.html
From eskimo1 at apple.com  Tue Nov  6 12:58:00 2007
From: eskimo1 at apple.com (Quinn)
Date: Tue Nov  6 13:02:38 2007
Subject: [launchd-dev] TN2083 "Daemons and Agents" update
Message-ID: <p0624080bc35684133168@[10.0.40.15]>

Greetings All

Just FYI, I've done an extensive overhaul of DTS Technote 2083 
"Daemons and Agents" to account for many of the changes in process 
management in Mac OS X 10.5.  That update is now on the Apple 
developer web site.

   <http://developer.apple.com/technotes/tn2005/tn2083.html>

Share and Enjoy
-- 
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
From bpkroth at wisc.edu  Thu Nov  8 20:17:22 2007
From: bpkroth at wisc.edu (bpkroth)
Date: Thu Nov  8 20:36:18 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <0DAF6FAF-BF2A-4496-B4C9-67D49BFC76B5@n8geil.de>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
	<F307520B-11B6-453C-BE38-52D318588964@apple.com>
	<13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
	<65427801-906D-4944-95F2-E2E8B665E952@apple.com>
	<0DAF6FAF-BF2A-4496-B4C9-67D49BFC76B5@n8geil.de>
Message-ID: <13661342.post@talk.nabble.com>


>> Do you have any firewall magic installed or configured? Is a pre- 
>> existing copy of the daemon already running?
>>
> I have! The build in one was on "set access for specific services and  
> applications". But that's all, no ipfw stuff.
> If I turn it of, or if I put bitlbee manually in the list of allowed  
> apps I can connect to it. BUT why am I not asked whether or not to  
> allow the connection in the GUI? This feels like a GUI bug to me.

> But it works now. Thank you.


I'm still having this problem.  I see where to set "Allow all incoming
connection" and that also fixes it for me.  However, if I specify the
location of bitlbee and use "Set access for specific services and
applications" I still get the "bind() operation not permitted" error.  That
was all in Preferences -> Security -> Firewall.  Is there another place I
should be looking?

Thanks,
Brian
-- 
View this message in context: http://www.nabble.com/bitlbee---xinetd-to-launchd-tf4734511.html#a13661342
Sent from the Launchd mailing list archive at Nabble.com.

From kvv at apple.com  Fri Nov  9 17:50:46 2007
From: kvv at apple.com (Kevin Van Vechten)
Date: Fri Nov  9 17:49:24 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <13661342.post@talk.nabble.com>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
	<F307520B-11B6-453C-BE38-52D318588964@apple.com>
	<13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
	<65427801-906D-4944-95F2-E2E8B665E952@apple.com>
	<0DAF6FAF-BF2A-4496-B4C9-67D49BFC76B5@n8geil.de>
	<13661342.post@talk.nabble.com>
Message-ID: <E701CDB4-B524-4221-AE04-5885BC1E507A@apple.com>

On Nov 8, 2007, at 8:17 PM, bpkroth wrote:

> I'm still having this problem.  I see where to set "Allow all incoming
> connection" and that also fixes it for me.  However, if I specify the
> location of bitlbee and use "Set access for specific services and
> applications" I still get the "bind() operation not permitted"  
> error.  That
> was all in Preferences -> Security -> Firewall.  Is there another  
> place I
> should be looking?

I'm afraid you've moved out of the area of expertise on this launchd- 
dev list.  Your question might be better asked on one of the more  
general Darwin lists (i.e. darwin-dev@lists.apple.com) where someone  
more familiar with the Leopard firewall may be lurking.

- Kevin
From bpkroth at wisc.edu  Fri Nov  9 19:49:04 2007
From: bpkroth at wisc.edu (bpkroth)
Date: Sat Nov 10 13:30:56 2007
Subject: [launchd-dev] bitlbee - xinetd to launchd
In-Reply-To: <E701CDB4-B524-4221-AE04-5885BC1E507A@apple.com>
References: <A85FCAD0-3639-40C8-A16E-9F3E97AB3EB0@n8geil.de>
	<F307520B-11B6-453C-BE38-52D318588964@apple.com>
	<13BEBB4E-D1F3-44DC-829D-4CC647F51A30@n8geil.de>
	<65427801-906D-4944-95F2-E2E8B665E952@apple.com>
	<0DAF6FAF-BF2A-4496-B4C9-67D49BFC76B5@n8geil.de>
	<13661342.post@talk.nabble.com>
	<E701CDB4-B524-4221-AE04-5885BC1E507A@apple.com>
Message-ID: <13679082.post@talk.nabble.com>



Kevin Van Vechten-2 wrote:
> 
> On Nov 8, 2007, at 8:17 PM, bpkroth wrote:
> 
>> I'm still having this problem.  I see where to set "Allow all incoming
>> connection" and that also fixes it for me.  However, if I specify the
>> location of bitlbee and use "Set access for specific services and
>> applications" I still get the "bind() operation not permitted"  
>> error.  That
>> was all in Preferences -> Security -> Firewall.  Is there another  
>> place I
>> should be looking?
> 
> I'm afraid you've moved out of the area of expertise on this launchd- 
> dev list.  Your question might be better asked on one of the more  
> general Darwin lists (i.e. darwin-dev@lists.apple.com) where someone  
> more familiar with the Leopard firewall may be lurking.
> 
> - Kevin
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev
> 
> 

Turns out a reboot fixed my problem.

Thanks,
Brian
-- 
View this message in context: http://www.nabble.com/bitlbee---xinetd-to-launchd-tf4734511.html#a13679082
Sent from the Launchd mailing list archive at Nabble.com.

From hamish at gmail.com  Mon Nov 12 11:11:35 2007
From: hamish at gmail.com (Hamish Allan)
Date: Mon Nov 12 11:10:04 2007
Subject: [launchd-dev] Dynamic port listening
Message-ID: <597e7edb0711121111m789de918s215e419ad099268f@mail.gmail.com>

Hi,

Is it possible to make a LaunchAgent listen on the first free port
rather than a specific one?

I'm trying to forward an HTTP connection on demand (over SSH), but
rather than choose a specific local port I'd rather just choose a free
one and then advertise it using Bonjour. So I also need to know what
the chosen port was and pass it to dns-sd.

A related question: is it possible (without writing to /etc/services)
to make LaunchAgent listen on a port decided dynamically? i.e. would
it be possible to use NAT-PMP to forward an external port to the first
available local port, and then have a LaunchAgent listen on that port?

Thanks,
Hamish
From zarzycki at apple.com  Mon Nov 12 11:15:02 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Mon Nov 12 11:13:26 2007
Subject: [launchd-dev] Dynamic port listening
In-Reply-To: <597e7edb0711121111m789de918s215e419ad099268f@mail.gmail.com>
References: <597e7edb0711121111m789de918s215e419ad099268f@mail.gmail.com>
Message-ID: <666E20F4-69CF-4178-9C07-6B8469C85768@apple.com>

On Nov 12, 2007, at 11:11 AM, Hamish Allan wrote:

> Hi,
>
> Is it possible to make a LaunchAgent listen on the first free port
> rather than a specific one?

Sure, set the port to zero. The kernel will dynamically assign a free  
port.


>
>
> I'm trying to forward an HTTP connection on demand (over SSH), but
> rather than choose a specific local port I'd rather just choose a free
> one and then advertise it using Bonjour. So I also need to know what
> the chosen port was and pass it to dns-sd.

Actually, the launchd code should handle that for you. Just set  
Bonjour to true in the plist.


>
>
> A related question: is it possible (without writing to /etc/services)
> to make LaunchAgent listen on a port decided dynamically? i.e. would
> it be possible to use NAT-PMP to forward an external port to the first
> available local port, and then have a LaunchAgent listen on that port?

I'm not sure what NAT-PMP is or how it applies to this scenario?

davez
From hamish at gmail.com  Mon Nov 12 14:51:16 2007
From: hamish at gmail.com (Hamish Allan)
Date: Mon Nov 12 14:49:41 2007
Subject: [launchd-dev] Dynamic port listening
In-Reply-To: <666E20F4-69CF-4178-9C07-6B8469C85768@apple.com>
References: <597e7edb0711121111m789de918s215e419ad099268f@mail.gmail.com>
	<666E20F4-69CF-4178-9C07-6B8469C85768@apple.com>
Message-ID: <597e7edb0711121451w2458e27coed77033d91c565b4@mail.gmail.com>

Hi Dave,

On Nov 12, 2007 7:15 PM, Dave Zarzycki <zarzycki@apple.com> wrote:

> Sure, set the port to zero. The kernel will dynamically assign a free
> port.

Ah, thanks.

> Actually, the launchd code should handle that for you. Just set
> Bonjour to true in the plist.

Unfortunately, the SSH port is bound only to the loopback interface
(so that others on my LAN cannot access it). As such, I need to
register the service as being on localhost rather than
mymachine.local, as per the following:

$ dns-sd -P ServiceName _http._tcp . <port> localhost 127.0.0.1

However, the Bonjour key (which I set to "http" as the SockServiceName
is 0) causes it to be registered as being on mymachine.local. Can I do
anything about this?

Thanks,
Hamish
From hamish at gmail.com  Tue Nov 13 15:22:48 2007
From: hamish at gmail.com (Hamish Allan)
Date: Tue Nov 13 15:21:08 2007
Subject: [launchd-dev] Dynamic port listening
In-Reply-To: <597e7edb0711121451w2458e27coed77033d91c565b4@mail.gmail.com>
References: <597e7edb0711121111m789de918s215e419ad099268f@mail.gmail.com>
	<666E20F4-69CF-4178-9C07-6B8469C85768@apple.com>
	<597e7edb0711121451w2458e27coed77033d91c565b4@mail.gmail.com>
Message-ID: <597e7edb0711131522r5bd913f1g4032a7e59fcfed41@mail.gmail.com>

On Nov 12, 2007 10:51 PM, Hamish Allan <hamish@gmail.com> wrote:

> I need to register the [Bonjour] service as being on localhost rather than mymachine.local
> [...]
> Can I do anything about this?

To answer my own question: from examining the source code, it would
seem not. do_rendezvous_magic()'s call to DNSServiceRegister() is
currently hardcoded to advertise on all interfaces.

So to take another tack: is it possible to have launchd execute
arbitrary commands after binding to a port, with the addrinfo
available for substitution?

Thanks,
Hamish
From zarzycki at apple.com  Tue Nov 13 15:57:15 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Tue Nov 13 15:55:35 2007
Subject: [launchd-dev] Dynamic port listening
In-Reply-To: <597e7edb0711131522r5bd913f1g4032a7e59fcfed41@mail.gmail.com>
References: <597e7edb0711121111m789de918s215e419ad099268f@mail.gmail.com>
	<666E20F4-69CF-4178-9C07-6B8469C85768@apple.com>
	<597e7edb0711121451w2458e27coed77033d91c565b4@mail.gmail.com>
	<597e7edb0711131522r5bd913f1g4032a7e59fcfed41@mail.gmail.com>
Message-ID: <90C5E5B0-FCAE-4FFE-B933-782C2A5B8098@apple.com>


On Nov 13, 2007, at 3:22 PM, Hamish Allan wrote:

> On Nov 12, 2007 10:51 PM, Hamish Allan <hamish@gmail.com> wrote:
>
>> I need to register the [Bonjour] service as being on localhost  
>> rather than mymachine.local
>> [...]
>> Can I do anything about this?
>
> To answer my own question: from examining the source code, it would
> seem not. do_rendezvous_magic()'s call to DNSServiceRegister() is
> currently hardcoded to advertise on all interfaces.

Please file a bug to fix that.


> So to take another tack: is it possible to have launchd execute
> arbitrary commands after binding to a port, with the addrinfo
> available for substitution?

Nope.

davez

From hamish at gmail.com  Thu Nov 15 05:00:38 2007
From: hamish at gmail.com (Hamish Allan)
Date: Thu Nov 15 04:58:58 2007
Subject: [launchd-dev] Environment variables
Message-ID: <597e7edb0711150500p102e5c2ct9ac2ca750de1d478@mail.gmail.com>

Hi,

The man page for launchd.plist says:

SecureSocketWithKey <string>
This optional key is a variant of SockPathName. Instead of binding to
a known path, a securely generated socket is created and the path is
assigned to the environment variable that is inherited by all jobs
spawned by launchd.

However, the SSH_AUTH_SOCK environment variable generated by Leopard's
/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist doesn't seem
to be available to my ~/Library/LaunchAgents. E.g. the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://
www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>test.7B21D717-E7AE-4DB0-905F-7D40F8A6ABE2</string>
  <key>Program</key>
  <string>/usr/bin/env</string>
  <key>inetdCompatibility</key>
  <dict>
    <key>Wait</key>
    <false/>
  </dict>
  <key>Sockets</key>
  <dict>
    <key>Listeners</key>
    <dict>
      <key>SockNodeName</key>
      <string>127.0.0.1</string>
      <key>SockFamily</key>
      <string>IPv4</string>
      <key>SockServiceName</key>
      <string>34567</string>
    </dict>
  </dict>
</dict>
</plist>

when accessed via 'nc localhost 34567' generates a list of several
environment variables, none of which is SSH_AUTH_SOCK.

Is this the expected behaviour? If so, how can I make a LaunchAgent
for ssh that can access my ssh-agent across reboots?

Thanks,
Hamish
From zarzycki at apple.com  Thu Nov 15 09:16:42 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov 15 09:14:56 2007
Subject: [launchd-dev] Environment variables
In-Reply-To: <597e7edb0711150500p102e5c2ct9ac2ca750de1d478@mail.gmail.com>
References: <597e7edb0711150500p102e5c2ct9ac2ca750de1d478@mail.gmail.com>
Message-ID: <AEF907E7-4C78-4777-88AA-00071E088434@apple.com>

This is all context sensitive. Right now, the ssh-agent is only loaded  
into the GUI login context. The environment variable it exports is  
only available to the jobs associated with that session.

Where are you installing your plist?

If you're loading it by hand, what arguments are you passing to the  
'launchctl' tool?


davez


On Nov 15, 2007, at 5:00 AM, Hamish Allan wrote:

> Hi,
>
> The man page for launchd.plist says:
>
> SecureSocketWithKey <string>
> This optional key is a variant of SockPathName. Instead of binding to
> a known path, a securely generated socket is created and the path is
> assigned to the environment variable that is inherited by all jobs
> spawned by launchd.
>
> However, the SSH_AUTH_SOCK environment variable generated by Leopard's
> /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist doesn't seem
> to be available to my ~/Library/LaunchAgents. E.g. the following:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://
> www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <dict>
>  <key>Label</key>
>  <string>test.7B21D717-E7AE-4DB0-905F-7D40F8A6ABE2</string>
>  <key>Program</key>
>  <string>/usr/bin/env</string>
>  <key>inetdCompatibility</key>
>  <dict>
>    <key>Wait</key>
>    <false/>
>  </dict>
>  <key>Sockets</key>
>  <dict>
>    <key>Listeners</key>
>    <dict>
>      <key>SockNodeName</key>
>      <string>127.0.0.1</string>
>      <key>SockFamily</key>
>      <string>IPv4</string>
>      <key>SockServiceName</key>
>      <string>34567</string>
>    </dict>
>  </dict>
> </dict>
> </plist>
>
> when accessed via 'nc localhost 34567' generates a list of several
> environment variables, none of which is SSH_AUTH_SOCK.
>
> Is this the expected behaviour? If so, how can I make a LaunchAgent
> for ssh that can access my ssh-agent across reboots?
>
> Thanks,
> Hamish
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From hamish at gmail.com  Thu Nov 15 09:45:52 2007
From: hamish at gmail.com (Hamish Allan)
Date: Thu Nov 15 09:44:03 2007
Subject: [launchd-dev] Environment variables
In-Reply-To: <AEF907E7-4C78-4777-88AA-00071E088434@apple.com>
References: <597e7edb0711150500p102e5c2ct9ac2ca750de1d478@mail.gmail.com>
	<AEF907E7-4C78-4777-88AA-00071E088434@apple.com>
Message-ID: <597e7edb0711150945r590743d5i7c3f3e79c0975398@mail.gmail.com>

On Nov 15, 2007 5:16 PM, Dave Zarzycki <zarzycki@apple.com> wrote:

> This is all context sensitive. Right now, the ssh-agent is only loaded
> into the GUI login context. The environment variable it exports is
> only available to the jobs associated with that session.
>
> Where are you installing your plist?

~/Library/LaunchAgents

> If you're loading it by hand, what arguments are you passing to the
> 'launchctl' tool?

No arguments. I just tried passing '-S LoginWindow' but it reports
'nothing found to load' (even if I give it the full path of my .plist
file).

Thanks,
Hamish
From zarzycki at apple.com  Thu Nov 15 10:38:14 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov 15 10:36:27 2007
Subject: [launchd-dev] Environment variables
In-Reply-To: <597e7edb0711150945r590743d5i7c3f3e79c0975398@mail.gmail.com>
References: <597e7edb0711150500p102e5c2ct9ac2ca750de1d478@mail.gmail.com>
	<AEF907E7-4C78-4777-88AA-00071E088434@apple.com>
	<597e7edb0711150945r590743d5i7c3f3e79c0975398@mail.gmail.com>
Message-ID: <00C02314-2A1F-4FF4-A659-474E2D042129@apple.com>


On Nov 15, 2007, at 9:45 AM, Hamish Allan wrote:

> On Nov 15, 2007 5:16 PM, Dave Zarzycki <zarzycki@apple.com> wrote:
>
>> This is all context sensitive. Right now, the ssh-agent is only  
>> loaded
>> into the GUI login context. The environment variable it exports is
>> only available to the jobs associated with that session.
>>
>> Where are you installing your plist?
>
> ~/Library/LaunchAgents
>
>> If you're loading it by hand, what arguments are you passing to the
>> 'launchctl' tool?
>
> No arguments. I just tried passing '-S LoginWindow' but it reports
> 'nothing found to load' (even if I give it the full path of my .plist
> file).

That makes some amount of sense. The 'ssh-agent' job isn't configured  
to run in the LoginWindow context, and neither is your job's plist.

davez
From hamish at gmail.com  Thu Nov 15 11:40:07 2007
From: hamish at gmail.com (Hamish Allan)
Date: Thu Nov 15 11:38:19 2007
Subject: [launchd-dev] Environment variables
In-Reply-To: <00C02314-2A1F-4FF4-A659-474E2D042129@apple.com>
References: <597e7edb0711150500p102e5c2ct9ac2ca750de1d478@mail.gmail.com>
	<AEF907E7-4C78-4777-88AA-00071E088434@apple.com>
	<597e7edb0711150945r590743d5i7c3f3e79c0975398@mail.gmail.com>
	<00C02314-2A1F-4FF4-A659-474E2D042129@apple.com>
Message-ID: <597e7edb0711151140t58e969a2h2e3a82efcdb2efcf@mail.gmail.com>

On Nov 15, 2007 6:38 PM, Dave Zarzycki <zarzycki@apple.com> wrote:

> That makes some amount of sense. The 'ssh-agent' job isn't configured
> to run in the LoginWindow context, and neither is your job's plist.

Okay, I've RTFM now :) and launched successfully in the 'Aqua' context.

Thanks,
Hamish
From mattdefoor at gmail.com  Thu Nov 15 12:39:50 2007
From: mattdefoor at gmail.com (Matt DeFoor)
Date: Thu Nov 15 12:38:01 2007
Subject: [launchd-dev] Attaching to launchd via gdb?
Message-ID: <835919320711151239r687be980ue36feda3147c88d8@mail.gmail.com>

Is there a means to attach to and debug launchd? Or to attach to a per
user launchd process? I get the following when logged in as root and
trying to attach to launchd:

(gdb) attach launchd.1
Attaching to program: `/sbin/launchd', process 1.
Unable to attach to process-id 1: Operation not permitted (1).
This request requires that the target process be neither setuid nor
setgid and have the same real userid as the debugger, or that the
debugger be running with administrator privileges.

I'm trying to determine why the call to getpwuid() in
job_postfork_become_user() is failing. Here's a snippet from
system.log:

Nov 15 14:39:35 dc3 com.apple.launchd[1]
(com.apple.launchd.peruser.166128603[1036]): getpwuid("166128603")
failed
Nov 15 14:39:35 dc3 com.apple.launchd[1]
(com.apple.launchd.peruser.166128603[1036]): PID 1002
"authorizationhos" has no account to back it! Real/effective/saved
UIDs
: 0/166128603/0
Nov 15 14:39:35 dc3 com.apple.launchd[1]
(com.apple.launchd.peruser.166128603[1036]): PID 112
"authorizationhos" has no account to back it! Real/effective/saved
UIDs:
 0/166128603/0
Nov 15 14:39:35 dc3 com.apple.launchd[1]
(com.apple.launchd.peruser.166128603[1036]): Exited with exit code: 1
Nov 15 14:39:35 dc3 com.apple.launchd[1]
(com.apple.launchd.peruser.166128603): Throttling respawn: Will start
in 10 seconds

Cheers,
Matt
From zarzycki at apple.com  Thu Nov 15 14:28:23 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov 15 14:26:34 2007
Subject: [launchd-dev] Attaching to launchd via gdb?
In-Reply-To: <835919320711151239r687be980ue36feda3147c88d8@mail.gmail.com>
References: <835919320711151239r687be980ue36feda3147c88d8@mail.gmail.com>
Message-ID: <13449A18-8D70-4BD1-A467-DA8B36412FFF@apple.com>

Traditionally, the kernel doesn't allow debuggers to attach to PID 1.  
As the author of launchd, I haven't felt strong enough to get the  
kernel team to change that policy. I've learned to live with logging.  
You can enable logging by adding "log level debug" to /etc/ 
launchd.conf and adjusting /etc/syslog.conf to capture the generated  
messages.

Having said all that, based on the messages below, I'd be curious to  
figure how why those processes are running around with UID 166128603.  
Was that ever a valid UID on your system? For whatever it may be  
worth, getpwuid() is a shim around DirectoryService APIs and the  
DirectoryService daemon. I'd try to get in contact with them.

davez



On Nov 15, 2007, at 12:39 PM, Matt DeFoor wrote:

> Is there a means to attach to and debug launchd? Or to attach to a per
> user launchd process? I get the following when logged in as root and
> trying to attach to launchd:
>
> (gdb) attach launchd.1
> Attaching to program: `/sbin/launchd', process 1.
> Unable to attach to process-id 1: Operation not permitted (1).
> This request requires that the target process be neither setuid nor
> setgid and have the same real userid as the debugger, or that the
> debugger be running with administrator privileges.
>
> I'm trying to determine why the call to getpwuid() in
> job_postfork_become_user() is failing. Here's a snippet from
> system.log:
>
> Nov 15 14:39:35 dc3 com.apple.launchd[1]
> (com.apple.launchd.peruser.166128603[1036]): getpwuid("166128603")
> failed
> Nov 15 14:39:35 dc3 com.apple.launchd[1]
> (com.apple.launchd.peruser.166128603[1036]): PID 1002
> "authorizationhos" has no account to back it! Real/effective/saved
> UIDs
> : 0/166128603/0
> Nov 15 14:39:35 dc3 com.apple.launchd[1]
> (com.apple.launchd.peruser.166128603[1036]): PID 112
> "authorizationhos" has no account to back it! Real/effective/saved
> UIDs:
> 0/166128603/0
> Nov 15 14:39:35 dc3 com.apple.launchd[1]
> (com.apple.launchd.peruser.166128603[1036]): Exited with exit code: 1
> Nov 15 14:39:35 dc3 com.apple.launchd[1]
> (com.apple.launchd.peruser.166128603): Throttling respawn: Will start
> in 10 seconds
>
> Cheers,
> Matt
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From mattdefoor at gmail.com  Thu Nov 15 16:51:08 2007
From: mattdefoor at gmail.com (Matt DeFoor)
Date: Thu Nov 15 16:49:25 2007
Subject: [launchd-dev] Attaching to launchd via gdb?
In-Reply-To: <13449A18-8D70-4BD1-A467-DA8B36412FFF@apple.com>
References: <835919320711151239r687be980ue36feda3147c88d8@mail.gmail.com>
	<13449A18-8D70-4BD1-A467-DA8B36412FFF@apple.com>
Message-ID: <835919320711151651o16cdf0bay2d93577d1c9e0135@mail.gmail.com>

On Nov 15, 2007 5:28 PM, Dave Zarzycki <zarzycki@apple.com> wrote:
> Traditionally, the kernel doesn't allow debuggers to attach to PID 1.
> As the author of launchd, I haven't felt strong enough to get the
> kernel team to change that policy. I've learned to live with logging.
> You can enable logging by adding "log level debug" to /etc/
> launchd.conf and adjusting /etc/syslog.conf to capture the generated
> messages.
>

Thanks, will do.

> Having said all that, based on the messages below, I'd be curious to
> figure how why those processes are running around with UID 166128603.
> Was that ever a valid UID on your system? For whatever it may be
> worth, getpwuid() is a shim around DirectoryService APIs and the
> DirectoryService daemon. I'd try to get in contact with them.
>

I should have explained the unusually high UID in my first message.
The UID is generated by my Open Directory plugin. There's an algorithm
that generates them for users authenticated via the plugin. High UIDs
like that are also somewhat common in the AD plugin from what I
understand. Anyway, these high UIDs haven't been a problem pre-Leopard
GM. So, I'm a little suspicious about them. However, if I assign the
user a low UID (something like 600) I can still reproduce the error.

So, I've been spending quality time in the debugger trying to figure
out if there's something in my plugin that would be causing getpwuid()
to fail when/if it makes calls via DirectoryService. But, to this
point, I haven't seen anything unusual. Like I said, the code was
working fine from Panther to pre-Leopard GM.

Cheers,
Matt
From yaniv at aknin.name  Sat Nov 17 13:14:06 2007
From: yaniv at aknin.name (Yaniv Aknin)
Date: Sat Nov 17 13:12:08 2007
Subject: [launchd-dev] Getting user parameters as an agent
Message-ID: <ec3cf7fd0711171314j486ff321n5d53d4d2cacab4aa@mail.gmail.com>

Hi,

I'm writing a Tiger agent in Python and C which must run as root (it
enforces policies on the user). The agent should, however, know which user
it is enforcing (this is due to DiskArbitration's inability to create a
'global' Approval session affecting all users).

I've seen references on the list to the fact that an Agent in Tiger
absolutely must run as the user, no workarounds. This is pretty bad for me,
and would force me to do something crazy like running a daemon as root and
installing a tiny agent notifying the daemon a user came into existence (I'd
rather not link with Cocoa notifications).

Is there any way around that? Something saner than what I was suggesting?

Also, there's the issue of having launchd tell my agent which user it's
running for, either on the command line, as an environment variable, or
otherwise. And if I'm not asking for too much (I know I am...) - also
redirect stdout to a user-specific locations
(/var/log/my-app/log.$USERNAME).

How should I go about doing that? I couldn't find something relevant in
launchd.plist's manpage nor on the list's archive.

Many thanks,
 - Yaniv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071117/16947f7f/attachment-0001.html
From eskimo1 at apple.com  Mon Nov 19 02:34:22 2007
From: eskimo1 at apple.com (Quinn)
Date: Mon Nov 19 02:37:50 2007
Subject: [launchd-dev] Getting user parameters as an agent
In-Reply-To: <ec3cf7fd0711171314j486ff321n5d53d4d2cacab4aa@mail.gmail.com>
References: <ec3cf7fd0711171314j486ff321n5d53d4d2cacab4aa@mail.gmail.com>
Message-ID: <p0624088ec36716a21524@[10.0.40.15]>

At 23:14 +0200 17/11/07, Yaniv Aknin wrote:
>I'm writing a Tiger agent in Python and C which must run as root (it 
>enforces policies on the user). The agent should, however, know 
>which user it is enforcing (this is due to DiskArbitration's 
>inability to create a 'global' Approval session affecting all users).

It seems like this is where you're getting into trouble.  DiskArb is 
a daemon-safe framework.  I believe it should be possible for a 
daemon to implement a DAApprovalSessionRef that affects all mounts on 
the system.  Can you explain how you tried to do that and what went 
wrong?

S+E
-- 
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
From yaniv at aknin.name  Mon Nov 19 11:37:50 2007
From: yaniv at aknin.name (Yaniv Aknin)
Date: Mon Nov 19 11:35:43 2007
Subject: [launchd-dev] Getting user parameters as an agent
In-Reply-To: <p0624088ec36716a21524@10.0.40.15>
References: <ec3cf7fd0711171314j486ff321n5d53d4d2cacab4aa@mail.gmail.com>
	<p0624088ec36716a21524@10.0.40.15>
Message-ID: <ec3cf7fd0711191137o2bded470v4db9cea084a97ff1@mail.gmail.com>

My apologies, I'm unable to reproduce the behavior I saw earlier with
'user-specific' DAApprovalSessionRef. I haven't the faintest how it
happened, maybe a bug in some other part of my code and I jumped to
conclusions. Anyhow, if I hit an obstacle, I'd re-raise the issue with the
list.

Still, I'd be interested in knowing how can I provide username based
variables in launchd's plists, if at all possible.

Thanks and apologies again,
 - Yaniv

On 11/19/07, Quinn <eskimo1@apple.com> wrote:
>
> At 23:14 +0200 17/11/07, Yaniv Aknin wrote:
> >I'm writing a Tiger agent in Python and C which must run as root (it
> >enforces policies on the user). The agent should, however, know
> >which user it is enforcing (this is due to DiskArbitration's
> >inability to create a 'global' Approval session affecting all users).
>
> It seems like this is where you're getting into trouble.  DiskArb is
> a daemon-safe framework.  I believe it should be possible for a
> daemon to implement a DAApprovalSessionRef that affects all mounts on
> the system.  Can you explain how you tried to do that and what went
> wrong?
>
> S+E
> --
> Quinn "The Eskimo!"                    < http://www.apple.com/developer/>
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071119/a57d135f/attachment.html
From eskimo1 at apple.com  Mon Nov 19 12:41:48 2007
From: eskimo1 at apple.com (Quinn)
Date: Mon Nov 19 12:39:32 2007
Subject: [launchd-dev] Getting user parameters as an agent
In-Reply-To: <ec3cf7fd0711191137o2bded470v4db9cea084a97ff1@mail.gmail.com>
References: <ec3cf7fd0711171314j486ff321n5d53d4d2cacab4aa@mail.gmail.com>
	<p0624088ec36716a21524@10.0.40.15>
	<ec3cf7fd0711191137o2bded470v4db9cea084a97ff1@mail.gmail.com>
Message-ID: <p0624089fc367a0a36d62@[10.0.40.15]>

At 21:37 +0200 19/11/07, Yaniv Aknin wrote:
>My apologies, I'm unable to reproduce the behavior I saw earlier 
>with 'user-specific' DAApprovalSessionRef. I haven't the faintest 
>how it happened, maybe a bug in some other part of my code and I 
>jumped to conclusions. Anyhow, if I hit an obstacle, I'd re-raise 
>the issue with the list.

No worries.  I'm glad that you have things working the right way.

>Still, I'd be interested in knowing how can I provide username based 
>variables in launchd's plists, if at all possible.

OK, I'll take a stab at your original questions...

At 23:14 +0200 17/11/07, Yaniv Aknin wrote:
>I've seen references on the list to the fact that an Agent in Tiger 
>absolutely must run as the user

That's basically true, and it applies to both 10.4.x (where launchd 
agents have severe restrictions) and to 10.5 (where launchd agents 
are truly useful).

>no workarounds.

Well, there are always workarounds (-:  For example, you could make 
your agent setuid root.  However, that's a /really/ bad idea.  In 
general, we recommend that you separate the functionality that 
requires elevated privileges out of your agent and into a privileged 
daemon.  This has all sorts of security benefits.

We plan to publish a sample that illustrates this technique soon.

>Also, there's the issue of having launchd tell my agent which user 
>it's running for, either on the command line, as an environment 
>variable, or otherwise.

Given that the agent always runs as the user associated with the 
session, you can do this by calling <x-man-page://2/getuid>.

>And if I'm not asking for too much (I know I am...) - also redirect 
>stdout to a user-specific locations (/var/log/my-app/log.$USERNAME).

I don't think launchd provides a way to do this.  You'd have to write 
code in your agent to set up the user-specific log file.  This might 
make a good feature request.

<http://developer.apple.com/bugreporter/>

Or, better yet, log via <x-man-page://3/asl>.

S+E
-- 
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
From Louis.Granboulan at free.fr  Thu Nov 22 14:29:06 2007
From: Louis.Granboulan at free.fr (Louis Granboulan)
Date: Thu Nov 22 14:26:38 2007
Subject: [launchd-dev] Run job when network configuration changes
Message-ID: <CA734039-4F4A-4DDC-ABC4-FB0868612C70@free.fr>

Dear all,

I would like to support Jeremy Reichman's request, because I  
apparently have similar needs.

I have used the Kicker.xml technique to make automatic backups of my  
laptop.
However, this laptop connects to various networks, and should backup  
only when connected to the ones where enough bandwidth is available.
Moreover, one of such networks uses a 802.1x authentication, and I  
can backup only when authenticated. In that case, I go from a wired- 
non-authenticated connection to a wired-authenticated connection, and  
I need to launch the backup script after authentication.

Thanks,
Louis
From eskimo1 at apple.com  Mon Nov 26 01:47:51 2007
From: eskimo1 at apple.com (Quinn)
Date: Mon Nov 26 01:50:05 2007
Subject: [launchd-dev] Run job when network configuration changes
In-Reply-To: <CA734039-4F4A-4DDC-ABC4-FB0868612C70@free.fr>
References: <CA734039-4F4A-4DDC-ABC4-FB0868612C70@free.fr>
Message-ID: <p0624081ac37045e6d244@[10.0.40.15]>

At 23:29 +0100 22/11/07, Louis Granboulan wrote:
>I would like to support Jeremy Reichman's request, because I 
>apparently have similar needs.

Cool.  Please file a bug describing what you want to achieve:

<http://developer.apple.com/bugreporter/>

It may not be easy (or possible) to do what you want (because of 
layering constraints within the system) but, once we have an official 
bug report, we'll have a reason to investigate this properly.

S+E
-- 
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
From subscriber at gloaming.com  Mon Nov 26 16:20:20 2007
From: subscriber at gloaming.com (James Bucanek)
Date: Mon Nov 26 16:17:47 2007
Subject: [launchd-dev] User Deamon
Message-ID: <r219-1051-i386-258A0650D38A4F3F9C00963E070E1F7E@crocodile.local>

Welcome,

I was invited to bring this thread here by Quinn. My apologies 
if you've seen bits and pieced of this thread before; it's 
traveled around the Cocoa, Carbon, and MacNetworkProg lists 
before landing here.

I'm developing a backup and document archiving solution 
(<http://www.qrecall.com/> -- not an ad, just for reference).

The program provides "actions" that can be scheduled to run at 
regular intervals or in response to certain events. These 
actions should be performed whether the user is logged in or 
out. In fact, actions can be scheduled to run only when the user 
is logged out or because the user logged out.

There is a scheduler process which is responsible for managing 
all of this. The scheduler works on behalf of a single user. 
(Other users may have their own schedule/scheduler.) For 
security, the scheduler runs under the UID of that user.

So, what I have is a process that

- Needs to start up when the system boots and runs until the 
system shuts down, independent of whether the user is logged in 
or not.

- Runs as a single user (not as root) without any special privileges.

- Can be installed and removed without requiring administrative authorization.

In effect, I need a "User Daemon" -- a class of process that 
launchd does not provide.

I was simulating this (pretty well) using crontab. The crontab 
will allow non-admin users to install a cronjob that runs 
periodically and independently of their login session. 
Unfortunately, recent versions of Tiger and Leopard have become 
downright hostile towards user cronjobs, sending them SIGKILL 
signals whenever the user is logged out (without even the 
courtesy of a SIGTERM first!).

I'm now simulating this by installing a system-wide daemon for 
each user (/Library/LaunchDaemons/QRecallScheduler501.plist, 
.../QRecallScheduler502.plist, etc.). Each daemon is configured 
to run as that user (via the UserName property). But this 
requires administrative privileges to install/uninstall a 
non-privileged process. Beyond being annoying, it limits the 
usefulness of the application for non-admin users. And in the 
pit of my stomach, I feel that it presents a security hole.

I'm basically just throwing this out to the launchd team for 
comments, which might result in filing a feature request.

I also understand some of the potential problems in implementing 
user daemons. (For example, the logical place to place a user 
daemon configuration file would be in ~/Library/LaunchDaemons, 
but that obviously won't work with FileVault or users who mount 
their home folder over a network.) However, there are also 
potential solutions to some of these and there's also the 
principle that one shouldn't necessarily eliminate a feature 
just because 0.1% of the users can't use it. ;)

Any thoughts?

-- 
James Bucanek

From zarzycki at apple.com  Tue Nov 27 10:59:35 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Tue Nov 27 10:58:24 2007
Subject: [launchd-dev] User Deamon
In-Reply-To: <r219-1051-i386-258A0650D38A4F3F9C00963E070E1F7E@crocodile.local>
References: <r219-1051-i386-258A0650D38A4F3F9C00963E070E1F7E@crocodile.local>
Message-ID: <76BB6197-302E-48B3-BD47-04785453A00D@apple.com>

At the moment user-agents cannot be launched at boot. Otherwise the  
solution would be "perfect" (with the exception of FileVault and AFP  
home directories, but that is a different problem). Please file a bug/ 
enhancement-request on that.

I think your configuration file per user is the next best alternative  
in the Leopard timeframe.

Good luck,

davez



On Nov 26, 2007, at 4:20 PM, James Bucanek wrote:

> Welcome,
>
> I was invited to bring this thread here by Quinn. My apologies if  
> you've seen bits and pieced of this thread before; it's traveled  
> around the Cocoa, Carbon, and MacNetworkProg lists before landing  
> here.
>
> I'm developing a backup and document archiving solution (<http://www.qrecall.com/ 
> > -- not an ad, just for reference).
>
> The program provides "actions" that can be scheduled to run at  
> regular intervals or in response to certain events. These actions  
> should be performed whether the user is logged in or out. In fact,  
> actions can be scheduled to run only when the user is logged out or  
> because the user logged out.
>
> There is a scheduler process which is responsible for managing all  
> of this. The scheduler works on behalf of a single user. (Other  
> users may have their own schedule/scheduler.) For security, the  
> scheduler runs under the UID of that user.
>
> So, what I have is a process that
>
> - Needs to start up when the system boots and runs until the system  
> shuts down, independent of whether the user is logged in or not.
>
> - Runs as a single user (not as root) without any special privileges.
>
> - Can be installed and removed without requiring administrative  
> authorization.
>
> In effect, I need a "User Daemon" -- a class of process that launchd  
> does not provide.
>
> I was simulating this (pretty well) using crontab. The crontab will  
> allow non-admin users to install a cronjob that runs periodically  
> and independently of their login session. Unfortunately, recent  
> versions of Tiger and Leopard have become downright hostile towards  
> user cronjobs, sending them SIGKILL signals whenever the user is  
> logged out (without even the courtesy of a SIGTERM first!).
>
> I'm now simulating this by installing a system-wide daemon for each  
> user (/Library/LaunchDaemons/QRecallScheduler501.plist, .../ 
> QRecallScheduler502.plist, etc.). Each daemon is configured to run  
> as that user (via the UserName property). But this requires  
> administrative privileges to install/uninstall a non-privileged  
> process. Beyond being annoying, it limits the usefulness of the  
> application for non-admin users. And in the pit of my stomach, I  
> feel that it presents a security hole.
>
> I'm basically just throwing this out to the launchd team for  
> comments, which might result in filing a feature request.
>
> I also understand some of the potential problems in implementing  
> user daemons. (For example, the logical place to place a user daemon  
> configuration file would be in ~/Library/LaunchDaemons, but that  
> obviously won't work with FileVault or users who mount their home  
> folder over a network.) However, there are also potential solutions  
> to some of these and there's also the principle that one shouldn't  
> necessarily eliminate a feature just because 0.1% of the users can't  
> use it. ;)
>
> Any thoughts?
>
> -- 
> James Bucanek
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From zarzycki at apple.com  Tue Nov 27 11:02:28 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Tue Nov 27 11:01:18 2007
Subject: [launchd-dev] User Deamon
In-Reply-To: <76BB6197-302E-48B3-BD47-04785453A00D@apple.com>
References: <r219-1051-i386-258A0650D38A4F3F9C00963E070E1F7E@crocodile.local>
	<76BB6197-302E-48B3-BD47-04785453A00D@apple.com>
Message-ID: <047CC329-3482-4A2A-85CA-95312434AFD0@apple.com>

On Nov 27, 2007, at 10:59 AM, Dave Zarzycki wrote:

> At the moment user-agents cannot be launched at boot. Otherwise the  
> solution would be "perfect" (with the exception of FileVault and AFP  
> home directories, but that is a different problem). Please file a  
> bug/enhancement-request on that.

Er... With 'that' being the user-agents launch-at-boot problem...  
There isn't much I can do about the FileVault case...

>
>
> I think your configuration file per user is the next best  
> alternative in the Leopard timeframe.
>
> Good luck,
>
> davez
>
>
>
> On Nov 26, 2007, at 4:20 PM, James Bucanek wrote:
>
>> Welcome,
>>
>> I was invited to bring this thread here by Quinn. My apologies if  
>> you've seen bits and pieced of this thread before; it's traveled  
>> around the Cocoa, Carbon, and MacNetworkProg lists before landing  
>> here.
>>
>> I'm developing a backup and document archiving solution (<http://www.qrecall.com/ 
>> > -- not an ad, just for reference).
>>
>> The program provides "actions" that can be scheduled to run at  
>> regular intervals or in response to certain events. These actions  
>> should be performed whether the user is logged in or out. In fact,  
>> actions can be scheduled to run only when the user is logged out or  
>> because the user logged out.
>>
>> There is a scheduler process which is responsible for managing all  
>> of this. The scheduler works on behalf of a single user. (Other  
>> users may have their own schedule/scheduler.) For security, the  
>> scheduler runs under the UID of that user.
>>
>> So, what I have is a process that
>>
>> - Needs to start up when the system boots and runs until the system  
>> shuts down, independent of whether the user is logged in or not.
>>
>> - Runs as a single user (not as root) without any special privileges.
>>
>> - Can be installed and removed without requiring administrative  
>> authorization.
>>
>> In effect, I need a "User Daemon" -- a class of process that  
>> launchd does not provide.
>>
>> I was simulating this (pretty well) using crontab. The crontab will  
>> allow non-admin users to install a cronjob that runs periodically  
>> and independently of their login session. Unfortunately, recent  
>> versions of Tiger and Leopard have become downright hostile towards  
>> user cronjobs, sending them SIGKILL signals whenever the user is  
>> logged out (without even the courtesy of a SIGTERM first!).
>>
>> I'm now simulating this by installing a system-wide daemon for each  
>> user (/Library/LaunchDaemons/QRecallScheduler501.plist, .../ 
>> QRecallScheduler502.plist, etc.). Each daemon is configured to run  
>> as that user (via the UserName property). But this requires  
>> administrative privileges to install/uninstall a non-privileged  
>> process. Beyond being annoying, it limits the usefulness of the  
>> application for non-admin users. And in the pit of my stomach, I  
>> feel that it presents a security hole.
>>
>> I'm basically just throwing this out to the launchd team for  
>> comments, which might result in filing a feature request.
>>
>> I also understand some of the potential problems in implementing  
>> user daemons. (For example, the logical place to place a user  
>> daemon configuration file would be in ~/Library/LaunchDaemons, but  
>> that obviously won't work with FileVault or users who mount their  
>> home folder over a network.) However, there are also potential  
>> solutions to some of these and there's also the principle that one  
>> shouldn't necessarily eliminate a feature just because 0.1% of the  
>> users can't use it. ;)
>>
>> Any thoughts?
>>
>> -- 
>> James Bucanek
>>
>> _______________________________________________
>> launchd-dev mailing list
>> launchd-dev@lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/launchd-dev
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From subscriber at gloaming.com  Wed Nov 28 22:28:25 2007
From: subscriber at gloaming.com (James Bucanek)
Date: Wed Nov 28 22:26:00 2007
Subject: [launchd-dev] launchctl unload not working
Message-ID: <r219-1051-i386-4959CDB89A9441F488B441D457745398@crocodile.local>

Greetings,

I'm having a number of issues with launchd, particularly under 
Leopard. (Most, if not all, of this works just fine under 
Tiger.) My current, and most pressing issue, is trying to 
replace a daemon when the user upgrades their software.

Here's what I've got running

- A daemon is installed in 
/Library/LaunchDaemons/QRecallScheduler501.plist. I install the 
file by writing the plist then executing 'launchctl load 
/path-to-plist' as root. The .plist file has the UserName 
property set to an individual user.

This has been working (mostly) until I need to upgrade the 
user's software. I've tried various techniques, but the one I'm 
using now which I think should work doesn't.

Setup (if this makes any difference): The path to the daemon is 
a symbolic link to the actual binary in my application bundle. 
When the application is upgraded (via Sparkle), the application 
bundle is replaced with the new application bundle containing an 
updated daemon.

Step #1: Run 'launchctl unload -w /path-to-plist' as root. I 
wait for launchctl to return and then wait for the daemon to terminate.

Step #2: Delete the .plist at /Library/LaunchDaemons/QRecallScheduler501.plist.

Step #3: Write a new .plist at /Library/LaunchDaemons/QRecallScheduler501.plist

Step #4: Run 'launchctl load /path-to-plist' as root. Wait for 
launchctl to finish.

Here's what happens:

In step #1, launchctl returns with a status of 0. The daemon 
receives a SIGTERM and shuts down (2-3 seconds).

IMMEDIATELY, launchd starts the new deamon. I can only assume 
because the location of the updated binary is the same as the 
old one that was just terminated.

Steps #2 and #3 delete and rewrite the .plist.

Step #4 runs 'launchctl load' which returns with a status of 0. 
What I get in the console log is

11/28/07 4:09:44 PM [0x0-0x1e01e].com.qrecall.client[145] 
launchctl: Error unloading: com.qrecall.scheduler
11/28/07 4:09:56 PM com.apple.launchd[62] 
(com.qrecall.scheduler.501) Ignored this key: UserName

Contrary to the second error, the daemon is run with a UID of 
501 (which is correct -- the daemon will terminate if it's 
started as root).

The new daemon is then repeatedly restarted. (The daemon checks 
for a duplicate running instance of itself and terminates 
immediately if it's already running.)

11/28/07 4:09:57 PM com.apple.launchd[62] 
(com.qrecall.scheduler.501) Throttling respawn: Will start in 10 seconds
11/28/07 4:10:07 PM com.apple.launchd[62] 
(com.qrecall.scheduler.501) Throttling respawn: Will start in 10 seconds
11/28/07 4:10:17 PM com.apple.launchd[62] 
(com.qrecall.scheduler.501) Throttling respawn: Will start in 10 seconds
11/28/07 4:10:27 PM com.apple.launchd[62] 
(com.qrecall.scheduler.501) Throttling respawn: Will start in 10 seconds

The really bad part is the instance of the daemon that is 
running does not seem to be running in the correct 
environment/namespace. When it launches a sub-process it 
attempts to connect with it using Mach ports; The connection 
fails. Restarting the OS doesn't fix the problem.

I think the problem is that (in Leopard) there seems to be two 
instances of launchd running: One as root and one as user 501. 
But I'm getting very confused as to which one I should be trying 
to deal with.

I changed the code to call launchctl while running as user 501. 
That sometimes works and sometimes doesn't. If I can get the 
daemon to stop and issue 'launchctl load /...' as user 501, the 
daemon starts working: specifically, it can communication with 
the sub-processes that it starts. Once started using 'launchctl' 
as user 501 it can be stopped again using launchctl as 501. But 
after a restart, it's running in the wrong namespace again and I 
have to perform a 'sudo launchctl unload' to get it to stop.

So after an entire day, I'm really confused as to what launchctl 
commands I should be issuing to replace a running deamon, in 
what order, and using what UID.

James
-- 
James Bucanek

From kvv at apple.com  Wed Nov 28 23:08:49 2007
From: kvv at apple.com (Kevin Van Vechten)
Date: Wed Nov 28 23:07:32 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <r219-1051-i386-4959CDB89A9441F488B441D457745398@crocodile.local>
References: <r219-1051-i386-4959CDB89A9441F488B441D457745398@crocodile.local>
Message-ID: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>

I recommend reading the "Daemonomicon" <http://developer.apple.com/technotes/tn2005/tn2083.html#SECDAEMONOMICON 
 >.

Short summary pertinent to your symptoms:

- Root (uid 0) launchd loads jobs from LaunchDameons directories.  Use  
`sudo launchctl` to communicate with it.
- Per-user (uid 501) launchd loads jobs from LaunchAgents  
directories.  Use `launchctl` to communicate with it.
- Per-user launchd ignores the UserName key because it does not have  
the privilege to execute as any other user than the current user.
- Per-user mach bootstrap is a sub-bootstrap of the root mach  
bootstrap: agents can lookup daemons, but daemons cannot lookup agents.

- Kevin


On Nov 28, 2007, at 10:28 PM, James Bucanek wrote:

> Greetings,
>
> I'm having a number of issues with launchd, particularly under  
> Leopard. (Most, if not all, of this works just fine under Tiger.) My  
> current, and most pressing issue, is trying to replace a daemon when  
> the user upgrades their software.
>
> Here's what I've got running
>
> - A daemon is installed in /Library/LaunchDaemons/ 
> QRecallScheduler501.plist. I install the file by writing the plist  
> then executing 'launchctl load /path-to-plist' as root. The .plist  
> file has the UserName property set to an individual user.
>
> This has been working (mostly) until I need to upgrade the user's  
> software. I've tried various techniques, but the one I'm using now  
> which I think should work doesn't.
>
> Setup (if this makes any difference): The path to the daemon is a  
> symbolic link to the actual binary in my application bundle. When  
> the application is upgraded (via Sparkle), the application bundle is  
> replaced with the new application bundle containing an updated daemon.
>
> Step #1: Run 'launchctl unload -w /path-to-plist' as root. I wait  
> for launchctl to return and then wait for the daemon to terminate.
>
> Step #2: Delete the .plist at /Library/LaunchDaemons/ 
> QRecallScheduler501.plist.
>
> Step #3: Write a new .plist at /Library/LaunchDaemons/ 
> QRecallScheduler501.plist
>
> Step #4: Run 'launchctl load /path-to-plist' as root. Wait for  
> launchctl to finish.
>
> Here's what happens:
>
> In step #1, launchctl returns with a status of 0. The daemon  
> receives a SIGTERM and shuts down (2-3 seconds).
>
> IMMEDIATELY, launchd starts the new deamon. I can only assume  
> because the location of the updated binary is the same as the old  
> one that was just terminated.
>
> Steps #2 and #3 delete and rewrite the .plist.
>
> Step #4 runs 'launchctl load' which returns with a status of 0. What  
> I get in the console log is
>
> 11/28/07 4:09:44 PM [0x0-0x1e01e].com.qrecall.client[145] launchctl:  
> Error unloading: com.qrecall.scheduler
> 11/28/07 4:09:56 PM com.apple.launchd[62] (com.qrecall.scheduler. 
> 501) Ignored this key: UserName
>
> Contrary to the second error, the daemon is run with a UID of 501  
> (which is correct -- the daemon will terminate if it's started as  
> root).
>
> The new daemon is then repeatedly restarted. (The daemon checks for  
> a duplicate running instance of itself and terminates immediately if  
> it's already running.)
>
> 11/28/07 4:09:57 PM com.apple.launchd[62] (com.qrecall.scheduler. 
> 501) Throttling respawn: Will start in 10 seconds
> 11/28/07 4:10:07 PM com.apple.launchd[62] (com.qrecall.scheduler. 
> 501) Throttling respawn: Will start in 10 seconds
> 11/28/07 4:10:17 PM com.apple.launchd[62] (com.qrecall.scheduler. 
> 501) Throttling respawn: Will start in 10 seconds
> 11/28/07 4:10:27 PM com.apple.launchd[62] (com.qrecall.scheduler. 
> 501) Throttling respawn: Will start in 10 seconds
>
> The really bad part is the instance of the daemon that is running  
> does not seem to be running in the correct environment/namespace.  
> When it launches a sub-process it attempts to connect with it using  
> Mach ports; The connection fails. Restarting the OS doesn't fix the  
> problem.
>
> I think the problem is that (in Leopard) there seems to be two  
> instances of launchd running: One as root and one as user 501. But  
> I'm getting very confused as to which one I should be trying to deal  
> with.
>
> I changed the code to call launchctl while running as user 501. That  
> sometimes works and sometimes doesn't. If I can get the daemon to  
> stop and issue 'launchctl load /...' as user 501, the daemon starts  
> working: specifically, it can communication with the sub-processes  
> that it starts. Once started using 'launchctl' as user 501 it can be  
> stopped again using launchctl as 501. But after a restart, it's  
> running in the wrong namespace again and I have to perform a 'sudo  
> launchctl unload' to get it to stop.
>
> So after an entire day, I'm really confused as to what launchctl  
> commands I should be issuing to replace a running deamon, in what  
> order, and using what UID.
>
> James
> -- 
> James Bucanek
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From subscriber at gloaming.com  Thu Nov 29 07:51:47 2007
From: subscriber at gloaming.com (James Bucanek)
Date: Thu Nov 29 07:49:02 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
Message-ID: <r219-1051-i386-DDD71361D31D4E59B070F23F6BB26836@crocodile.local>

Kevin Van Vechten <mailto:kvv@apple.com> wrote (Wednesday, 
November 28, 2007 12:08 AM -0800):

>I recommend reading the "Daemonomicon" <http://developer.apple.com/technotes/tn2005/tn2083.html#SECDAEMONOMICON>.

Been there, read that. (This is the one technote I keep on my desktop.)

>Short summary pertinent to your symptoms:
>
>- Root (uid 0) launchd loads jobs from LaunchDameons directories.  Use `sudo launchctl` to communicate with it.

Exactly. Since this is a daemon installed in 
/Library/LaunchDaemons I was forking launchctl when running as 
root. But that's when all the trouble started. :(

>- Per-user (uid 501) launchd loads jobs from LaunchAgents directories.  Use `launchctl` to communicate with it.

This isn't an agent.

>- Per-user launchd ignores the UserName key because it does not have the privilege to execute as any other user than the current user.
>- Per-user mach bootstrap is a sub-bootstrap of the root mach bootstrap: agents can lookup daemons, but daemons cannot lookup agents.

I'll try to clean out my system (each instance of launchd seems 
to have its own, persistent, history of what's been loaded and 
unloaded) and run my tests again verifying that each execution 
of launchctl occurs when running as root. From your notes, and 
reading technote 2083, it appears that I was doing (or I 
*thought* I was doing) exactly what I I should have been doing: 
Copy the .plist file to /Library/LaunchDaemons, then invoke 
'launchctl load ...' as root to install the daemon and 
'launchctl unload ...' to uninstall the daemon.

James
-- 
James Bucanek

From hamish at gmail.com  Thu Nov 29 08:08:01 2007
From: hamish at gmail.com (Hamish Allan)
Date: Thu Nov 29 08:05:11 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <r219-1051-i386-4959CDB89A9441F488B441D457745398@crocodile.local>
References: <r219-1051-i386-4959CDB89A9441F488B441D457745398@crocodile.local>
Message-ID: <597e7edb0711290808q33a772e0s41184bbab92ac2fe@mail.gmail.com>

On Nov 29, 2007 6:28 AM, James Bucanek <subscriber@gloaming.com> wrote:

> The really bad part is the instance of the daemon that is
> running does not seem to be running in the correct
> environment/namespace. When it launches a sub-process it
> attempts to connect with it using Mach ports; The connection
> fails. Restarting the OS doesn't fix the problem.

Have you tried passing various different sessiontypes (Background,
StandardIO and System) to launchctl? I'd have thought that if this
worked, so would an OS restart, but it might be worth a try.

Hamish
From zarzycki at apple.com  Thu Nov 29 08:58:21 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov 29 08:57:03 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <r219-1051-i386-DDD71361D31D4E59B070F23F6BB26836@crocodile.local>
References: <r219-1051-i386-DDD71361D31D4E59B070F23F6BB26836@crocodile.local>
Message-ID: <9F8308C2-10FD-44A4-BE85-B99492B17212@apple.com>

James,

You're clearly seen where the OS is headed. For better and for worse,  
you have also are discovering the edge cases of where our vision isn't  
completely implemented. Let's have a conference call. I'll contact you  
offline. For the rest of the people on this email list, please note, I  
cannot offer this level of service to any developer/customer, but at  
the moment, I think I have the time.

davez


On Nov 29, 2007, at 7:51 AM, James Bucanek wrote:

> Kevin Van Vechten <mailto:kvv@apple.com> wrote (Wednesday, November  
> 28, 2007 12:08 AM -0800):
>
>> I recommend reading the "Daemonomicon" <http://developer.apple.com/technotes/tn2005/tn2083.html#SECDAEMONOMICON 
>> >.
>
> Been there, read that. (This is the one technote I keep on my  
> desktop.)
>
>> Short summary pertinent to your symptoms:
>>
>> - Root (uid 0) launchd loads jobs from LaunchDameons directories.   
>> Use `sudo launchctl` to communicate with it.
>
> Exactly. Since this is a daemon installed in /Library/LaunchDaemons  
> I was forking launchctl when running as root. But that's when all  
> the trouble started. :(
>
>> - Per-user (uid 501) launchd loads jobs from LaunchAgents  
>> directories.  Use `launchctl` to communicate with it.
>
> This isn't an agent.
>
>> - Per-user launchd ignores the UserName key because it does not  
>> have the privilege to execute as any other user than the current  
>> user.
>> - Per-user mach bootstrap is a sub-bootstrap of the root mach  
>> bootstrap: agents can lookup daemons, but daemons cannot lookup  
>> agents.
>
> I'll try to clean out my system (each instance of launchd seems to  
> have its own, persistent, history of what's been loaded and  
> unloaded) and run my tests again verifying that each execution of  
> launchctl occurs when running as root. From your notes, and reading  
> technote 2083, it appears that I was doing (or I *thought* I was  
> doing) exactly what I I should have been doing: Copy the .plist file  
> to /Library/LaunchDaemons, then invoke 'launchctl load ...' as root  
> to install the daemon and 'launchctl unload ...' to uninstall the  
> daemon.
>
> James
> -- 
> James Bucanek
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev

From subscriber at gloaming.com  Thu Nov 29 11:36:39 2007
From: subscriber at gloaming.com (James Bucanek)
Date: Thu Nov 29 11:33:53 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
Message-ID: <r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>

Hello again,

I've documented a little more of my problem. I think I might 
have a solution, but I'm still trying to understand what's going 
on and why. (Skip to the summary of the problem at the end if 
you want the short version.)

- A launchd.plist configuration file is stored it in 
/Library/LaunchDaemons/. The configuration includes the 
UserName=james property.  I made sure everything was unloaded 
before starting.

- Wrote a little script so I can see what's going on
     echo 'per-user'; launchctl list | fgrep -i qre
     echo 'per-user namespace'; launchctl bslist | fgrep -i qre
     echo 'root'; sudo launchctl list | fgrep -i qre
     echo 'root namespace'; sudo launchctl bslist | fgrep -i qre

- Load the daemon using the per-user launchd

crocodile:~ james$ launchctl load  /Library/LaunchDaemons/QRecallScheduler501.plist

crocodile:~ james$ ~/Desktop/seedaemons.sh
per-user
789 -   [0x0-0x4d04d].com.qrecall.client
115 -   [0x0-0x16016].com.qrecall.monitor
1251    -   0x1109d0.QRecallScheduler
1250    -   com.qrecall.scheduler.501
per-user namespace
A  QRecallMonitor
root
root namespace

(Ignore the extra child instance of QRecallScheduler; the daemon 
spawns a copy of itself to generate notifications -- a solution 
that I'm going to replace with another mechanism.)

I can see that the scheduler is running in the context of the 
per-user launchd. When it starts up its helper process, that too 
appears in the context of the user session:

crocodile:~ james$ ~/Desktop/seedaemons.sh
per-user
789 -   [0x0-0x4d04d].com.qrecall.client
115 -   [0x0-0x16016].com.qrecall.monitor
1263    -   0x1112c0.QRecallHelper
1251    -   0x1109d0.QRecallScheduler
1250    -   com.qrecall.scheduler.501
per-user namespace
A  QRecallMonitor
root
root namespace

After starting the helper tool, the scheduler connects with the 
helper and does its thing. So far, so good.

Now, I try to install the scheduler process as a system-wide daemon.

crocodile:~ james$ launchctl unload /Library/LaunchDaemons/QRecallScheduler501.plist

crocodile:~ james$ ~/Desktop/seedaemons.sh
per-user
789 -   [0x0-0x4d04d].com.qrecall.client
115 -   [0x0-0x16016].com.qrecall.monitor
per-user namespace
A  QRecallMonitor
root
root namespace

(All traces of the scheduler are gone.)

crocodile:~ james$ sudo launchctl load /Library/LaunchDaemons/QRecallScheduler501.plist

crocodile:~ james$ ~/Desktop/seedaemons.sh
per-user
789 -   [0x0-0x4d04d].com.qrecall.client
115 -   [0x0-0x16016].com.qrecall.monitor
1170    -   0x10dcc0.QRecallScheduler
1167    -   0x1109d0.QRecallScheduler
per-user namespace
A  QRecallMonitor
root
1170    -   0x10be90.QRecallScheduler
1167    -   com.qrecall.scheduler.501
root namespace
A  QRecallScheduler.501

It looks OK. The scheduler appears in the bootstrap launchd and 
also in the context of the per-user launchd (since I assume that 
the per-user launchd inherits everything from its parent). The 
"QRecallScheduler.501" is its registered Mach communications port.

Now when the scheduler starts the helper tool:

crocodile:~ james$ ~/Desktop/seedaemons.sh
per-user
789 -   [0x0-0x4d04d].com.qrecall.client
115 -   [0x0-0x16016].com.qrecall.monitor
1182    -   0x10df80.QRecallHelper
1170    -   0x10dcc0.QRecallScheduler
1167    -   0x1109d0.QRecallScheduler
per-user namespace
A  QRecallMonitor
root
1182    -   0x10b0b0.QRecallHelper
1170    -   0x10be90.QRecallScheduler
1167    -   com.qrecall.scheduler.501
root namespace
A  QRecallScheduler.501

The helper process appears in both contexts, but its 
communications port doesn't appear in the bootstrap namespace. 
The helper successfully registers its distribute objects 
connection port, but when the scheduler process attempt to 
connect with that port it fails.

It appears that the problem is this: The scheduler is started by 
the bootstrap launchd. It creates and registers a Mach port for 
communications. That works. The scheduler then launches a child 
process (the helper, using NSTask), but when it tries to connect 
with the Mach port created by the helper that doesn't work. No 
process can see the port and it doesn't appear in the boostrap 
namespace according to launchctl, even though the helper is told 
that the port was successfully created and registered.

-- 
James Bucanek

From hamish at gmail.com  Thu Nov 29 15:50:22 2007
From: hamish at gmail.com (Hamish Allan)
Date: Thu Nov 29 15:47:31 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
References: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
	<r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
Message-ID: <597e7edb0711291550p78b29417v3bd64edd3499dd26@mail.gmail.com>

A quick query: do the five sessiontypes (Aqua, LoginWindow,
Background, StandardIO and System) correspond to the five locations
(~/Library/LaunchAgents, /Library/LaunchAgents,
/Library/LaunchDaemons, /System/Library/LaunchAgents,
/System/Library/LaunchDaemons)?

If not, how should we interpret the meaning of the sessiontypes?

Hamish
From kvv at apple.com  Thu Nov 29 16:32:05 2007
From: kvv at apple.com (Kevin Van Vechten)
Date: Thu Nov 29 16:31:00 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
References: <r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
Message-ID: <9E516C51-73BB-4CAC-A579-915DDE3111DD@apple.com>



On Nov 29, 2007, at 11:36 AM, James Bucanek wrote:

> The helper process appears in both contexts, but its communications  
> port doesn't appear in the bootstrap namespace. The helper  
> successfully registers its distribute objects connection port, but  
> when the scheduler process attempt to connect with that port it fails.

> It appears that the problem is this: The scheduler is started by the  
> bootstrap launchd. It creates and registers a Mach port for  
> communications. That works. The scheduler then launches a child  
> process (the helper, using NSTask), but when it tries to connect  
> with the Mach port created by the helper that doesn't work. No  
> process can see the port and it doesn't appear in the boostrap  
> namespace according to launchctl, even though the helper is told  
> that the port was successfully created and registered.


Just to clear up some terminology...

A bootstrap is a namespace for looking up mach services by name.  I  
would describe the above as "the helper's port does not appear in the  
root bootstrap."  And "the scheduler is started by the root launchd."

> crocodile:~ james$ ~/Desktop/seedaemons.sh

> per-user
> 789 -   [0x0-0x4d04d].com.qrecall.client
> 115 -   [0x0-0x16016].com.qrecall.monitor
> 1182    -   0x10df80.QRecallHelper
> 1170    -   0x10dcc0.QRecallScheduler
> 1167    -   0x1109d0.QRecallScheduler
> per-user namespace
> A  QRecallMonitor
> root
> 1182    -   0x10b0b0.QRecallHelper
> 1170    -   0x10be90.QRecallScheduler
> 1167    -   com.qrecall.scheduler.501
> root namespace
> A  QRecallScheduler.501


This output doesn't actually tell us which bootstrap the QRecallHelper  
or QRecallScheduler are running in.  All it tells us is that both of  
these processes have made themselves known to each of these launchd  
processes (which could have happened a number of ways).

The fact that the lookup fails in the root bootstrap strongly implies  
the helper is registered in the per-user bootstrap (if it's registered  
at all).  What is the name of the helper's registration?  (I'm  
assuming it's neither "QRecallScheduler.501" nor "QRecallMonitor"  
which are the only two names you've listed.)

As an aside, which API are you using to register the mach port?  
bootstrap_register? CFMessagePort?

- Kevin
From subscriber at gloaming.com  Thu Nov 29 17:12:43 2007
From: subscriber at gloaming.com (James Bucanek)
Date: Thu Nov 29 17:09:54 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <9E516C51-73BB-4CAC-A579-915DDE3111DD@apple.com>
Message-ID: <r219-1051-i386-A2A3C81816C747D48FCEDA0B1C8279CC@crocodile.local>

Kevin Van Vechten <mailto:kvv@apple.com> wrote (Thursday, 
November 29, 2007 5:32 PM -0800):

>Just to clear up some terminology...
>
>A bootstrap is a namespace for looking up mach services by name.  I
>would describe the above as "the helper's port does not appear in the
>root bootstrap."  And "the scheduler is started by the root launchd."

That's correct.

>>crocodile:~ james$ ~/Desktop/seedaemons.sh
>
>>per-user
>>789 -   [0x0-0x4d04d].com.qrecall.client
>>115 -   [0x0-0x16016].com.qrecall.monitor
>>1182    -   0x10df80.QRecallHelper
>>1170    -   0x10dcc0.QRecallScheduler
>>1167    -   0x1109d0.QRecallScheduler
>>per-user namespace
>>A  QRecallMonitor
>>root
>>1182    -   0x10b0b0.QRecallHelper
>>1170    -   0x10be90.QRecallScheduler
>>1167    -   com.qrecall.scheduler.501
>>root namespace
>>A  QRecallScheduler.501
>
>
>This output doesn't actually tell us which bootstrap the QRecallHelper
>or QRecallScheduler are running in.  All it tells us is that both of
>these processes have made themselves known to each of these launchd
>processes (which could have happened a number of ways).
>
>The fact that the lookup fails in the root bootstrap strongly implies
>the helper is registered in the per-user bootstrap (if it's registered
>at all). What is the name of the helper's registration?  (I'm assuming
>it's neither "QRecallScheduler.501" nor "QRecallMonitor" which are the
>only two names you've listed.)

A helper is given a name that includes its user and a job 
number. So it would register a port with a name like "QRecallHelper.501.6f3b21e0".

>As an aside, which API are you using to register the mach port?
>bootstrap_register? CFMessagePort?

Both the scheduler and the helper register their distributed 
object connection using the following code (this is actually in 
a subroutine that's shared by all binaries, so I'm confident 
there are no differences between tasks):

     NSConnection* serverConnection = [NSConnection defaultConnection];
     if (![serverConnection registerName:serviceName])
         {
         // log error
         serverConnection = nil;
         }
     return (serverConnection);

-- 
James Bucanek

From kvv at apple.com  Thu Nov 29 17:14:11 2007
From: kvv at apple.com (Kevin Van Vechten)
Date: Thu Nov 29 17:12:50 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <597e7edb0711291550p78b29417v3bd64edd3499dd26@mail.gmail.com>
References: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
	<r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
	<597e7edb0711291550p78b29417v3bd64edd3499dd26@mail.gmail.com>
Message-ID: <54CAF08F-70F5-4BDB-88C0-7653C3026F8E@apple.com>


On Nov 29, 2007, at 3:50 PM, Hamish Allan wrote:

> A quick query: do the five sessiontypes (Aqua, LoginWindow,
> Background, StandardIO and System) correspond to the five locations
> (~/Library/LaunchAgents, /Library/LaunchAgents,
> /Library/LaunchDaemons, /System/Library/LaunchAgents,
> /System/Library/LaunchDaemons)?

No, it's not a direct mapping.

> If not, how should we interpret the meaning of the sessiontypes?

<http://developer.apple.com/technotes/tn2005/tn2083.html#TABLAUNCHAGENTSUBTYPES 
 >

- LaunchDaemons are always loaded exclusively by the root launchd.
- LaunchAgents are typically loaded by the per-user launchd (unless  
you log in as root, or have a "LoginWindow" agent as described below).

Here's a summary of sessions:

- LaunchDaemons are only loaded into the "System" session of the root  
launchd.  No per-user launchd has a "System" session.
- Unless otherwise specified by the LimitLoadToSessionType key in the  
plist, LaunchAgents are loaded into the "Aqua" session.

- The "Aqua" session is the same session all GUI Applications are  
executed in.
- Logins via SSH, telnet, and others are executed in a "StandardIO"  
session.
- Each user is given a single "Background" session.  Jobs in the  
"Background" session may live longer than the last logout of the user.

- The "LoginWindow" session is active when the system is at the login  
window.  It disappears once a user as logged in.

The list of directories is the result of:

{LaunchDaemons, LaunchAgents} x {~/Library, /Library, /System/Liberary}

However, ~/Library/LaunchDaemons is omitted because there is not yet a  
current user when the root launchd starts, and per-user launchd  
instances never execute daemons.

- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071129/12eb7f08/attachment.html
From zarzycki at apple.com  Thu Nov 29 17:20:33 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Thu Nov 29 17:19:13 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <54CAF08F-70F5-4BDB-88C0-7653C3026F8E@apple.com>
References: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
	<r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
	<597e7edb0711291550p78b29417v3bd64edd3499dd26@mail.gmail.com>
	<54CAF08F-70F5-4BDB-88C0-7653C3026F8E@apple.com>
Message-ID: <0941EBC9-7BED-49B8-993C-B6FBC538AD94@apple.com>

On Nov 29, 2007, at 5:14 PM, Kevin Van Vechten wrote:

>
> On Nov 29, 2007, at 3:50 PM, Hamish Allan wrote:
>
>> A quick query: do the five sessiontypes (Aqua, LoginWindow,
>> Background, StandardIO and System) correspond to the five locations
>> (~/Library/LaunchAgents, /Library/LaunchAgents,
>> /Library/LaunchDaemons, /System/Library/LaunchAgents,
>> /System/Library/LaunchDaemons)?
>
> No, it's not a direct mapping.
>
>> If not, how should we interpret the meaning of the sessiontypes?
>
> <http://developer.apple.com/technotes/tn2005/tn2083.html#TABLAUNCHAGENTSUBTYPES 
> >
>
> - LaunchDaemons are always loaded exclusively by the root launchd.
> - LaunchAgents are typically loaded by the per-user launchd (unless  
> you log in as root, or have a "LoginWindow" agent as described below).
>
> Here's a summary of sessions:
>
> - LaunchDaemons are only loaded into the "System" session of the  
> root launchd.  No per-user launchd has a "System" session.
> - Unless otherwise specified by the LimitLoadToSessionType key in  
> the plist, LaunchAgents are loaded into the "Aqua" session.
>
> - The "Aqua" session is the same session all GUI Applications are  
> executed in.
> - Logins via SSH, telnet, and others are executed in a "StandardIO"  
> session.
> - Each user is given a single "Background" session.  Jobs in the  
> "Background" session may live longer than the last logout of the user.
>
> - The "LoginWindow" session is active when the system is at the  
> login window.  It disappears once a user as logged in.
>
> The list of directories is the result of:
>
> {LaunchDaemons, LaunchAgents} x {~/Library, /Library, /System/ 
> Liberary}
>
> However, ~/Library/LaunchDaemons is omitted because there is not yet  
> a current user when the root launchd starts, and per-user launchd  
> instances never execute daemons.

For whatever it may be worth: In hindsight, there should never have  
been a LaunchAgent versus LaunchDaemon distinction. It just have been  
just LaunchJobs and the scoping should have been controlled by the  
LimitLoadToSessionType.

davez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071129/fc50ee8d/attachment-0001.html
From kvv at apple.com  Thu Nov 29 17:28:05 2007
From: kvv at apple.com (Kevin Van Vechten)
Date: Thu Nov 29 17:26:43 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <r219-1051-i386-A2A3C81816C747D48FCEDA0B1C8279CC@crocodile.local>
References: <r219-1051-i386-A2A3C81816C747D48FCEDA0B1C8279CC@crocodile.local>
Message-ID: <5439C329-2D39-4933-B34B-B7EADC7F1BF9@apple.com>


On Nov 29, 2007, at 5:12 PM, James Bucanek wrote:

> A helper is given a name that includes its user and a job number. So  
> it would register a port with a name like "QRecallHelper. 
> 501.6f3b21e0".

So then let me ask why you think that name has been registered in the  
root bootstrap when it doesn't appear in the following output?

>>    echo 'per-user namespace'; launchctl bslist | fgrep -i qre
>>    echo 'root namespace'; sudo launchctl bslist | fgrep -i qre

>> per-user namespace
>> A  QRecallMonitor
>

>> root namespace
>> A  QRecallScheduler.501

As you've indicated NSConnection's registerName is succeeding, we can  
probably assume that the name is being registered in _some_ bootstrap,  
but some subtlety of your NSTask approach may be landing it in a  
bootstrap that you don't expect.

- Kevin
From launchd at khiltd.com  Thu Nov 29 19:37:23 2007
From: launchd at khiltd.com (Nathan Duran)
Date: Thu Nov 29 19:34:33 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <54CAF08F-70F5-4BDB-88C0-7653C3026F8E@apple.com>
References: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
	<r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
	<597e7edb0711291550p78b29417v3bd64edd3499dd26@mail.gmail.com>
	<54CAF08F-70F5-4BDB-88C0-7653C3026F8E@apple.com>
Message-ID: <52CCFC76-1D5A-4692-AC7C-4E5B6CA2A996@khiltd.com>


On Nov 29, 2007, at 5:14 PM, Kevin Van Vechten wrote:

> Here's a summary of sessions:
>
> - LaunchDaemons are only loaded into the "System" session of the  
> root launchd.  No per-user launchd has a "System" session.
> - Unless otherwise specified by the LimitLoadToSessionType key in  
> the plist, LaunchAgents are loaded into the "Aqua" session.
>
> - The "Aqua" session is the same session all GUI Applications are  
> executed in.
> - Logins via SSH, telnet, and others are executed in a "StandardIO"  
> session.
> - Each user is given a single "Background" session.  Jobs in the  
> "Background" session may live longer than the last logout of the user.

What are the odds of this information finding its way into the  
launchctl man page? 
From subscriber at gloaming.com  Thu Nov 29 21:37:21 2007
From: subscriber at gloaming.com (James Bucanek)
Date: Thu Nov 29 21:34:34 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <5439C329-2D39-4933-B34B-B7EADC7F1BF9@apple.com>
Message-ID: <r219-1051-i386-C364220868104AA5AB977D10F9CA88CE@crocodile.local>

Kevin Van Vechten <mailto:kvv@apple.com> wrote (Thursday, 
November 29, 2007 6:28 PM -0800):

>On Nov 29, 2007, at 5:12 PM, James Bucanek wrote:
>
>>A helper is given a name that includes its user and a job 
>>number. So it would register a port with a name like "QRecallHelper.501.6f3b21e0".
>
>So then let me ask why you think that name has been registered in the
>root bootstrap when it doesn't appear in the following output?

I guess I wasn't clear. Since the registration isn't throwing 
any errors, I'm assuming that the helper is registering its name 
in *some* bootstrap. I expected that to be the same bootstrap as 
the parent process that launched it, but it's clearly not.

Would it help to know the parent of the scheduler daemon? I 
could add debug code to log the PPID of each process as it 
starts up.

>>>   echo 'per-user namespace'; launchctl bslist | fgrep -i qre
>>>   echo 'root namespace'; sudo launchctl bslist | fgrep -i qre
>
>>>per-user namespace
>>>A  QRecallMonitor
>>
>
>>>root namespace
>>>A  QRecallScheduler.501
>
>As you've indicated NSConnection's registerName is succeeding, we can
>probably assume that the name is being registered in _some_ bootstrap,
>but some subtlety of your NSTask approach may be landing it in a
>bootstrap that you don't expect.

The helper is either a normal executable or a SUID root 
executable (a la MoreAuthSample) that gets launched with:

+ (NSTask*)launchHelper:(NSString*)helperPath 
withCommand:(NSString*)commandName 
passingAuthorization:(AuthorizationRef)authorizationRef returningPortName:(NSString**)portNamePtr
{
     NSTask*     helperTask = [[NSTask new] autorelease];
     NSString*   portName = nil;

     NS_DURING
         // If a helper wasn't specified, use the bundled helper
         if (helperPath==nil)
             helperPath = [[NSBundle mainBundle] 
pathForResource:kHelperName ofType:nil];

         // Prepare the helper to execute
         [helperTask setLaunchPath:helperPath];
         // Redirect the task's stdin and stdout to these NSPipe 
objects, so we can talk to the task
         NSPipe*         inPipe = [NSPipe pipe];
         NSPipe*         outPipe = [NSPipe pipe];
         [helperTask setStandardInput:inPipe];
         [helperTask setStandardOutput:outPipe];
         NSFileHandle*   stdInHandle = [inPipe fileHandleForWriting];
         NSFileHandle*   stdOutHandle = [outPipe fileHandleForReading];

         // Start the task running
         [helperTask launch];

         ...

Followed by a bunch of convoluted code to passes all of the 
startup parameters to the helper via stdin (which the helper 
does get, because those get logged as the helper starts up).

My assumption was that [NSTask launch] would start the process 
in the same environment/session/bootstrap as the parent process 
but something seems to be interfering with that.

I can see a couple of possible workarounds:

- Figure out why the helper's ports aren't getting registered in 
a namespace that's accessible by its parent. Maybe I need to use 
something other than NSTask to start the child process.

- Return (once again!) to using UNIX domain sockets for 
communications, which don't have these kinds of scoping issues.
-- 
James Bucanek

From zarzycki at apple.com  Fri Nov 30 09:41:54 2007
From: zarzycki at apple.com (Dave Zarzycki)
Date: Fri Nov 30 09:40:29 2007
Subject: [launchd-dev] launchctl unload not working
In-Reply-To: <52CCFC76-1D5A-4692-AC7C-4E5B6CA2A996@khiltd.com>
References: <F58F3A61-BF64-44AD-A773-13DA91E1C99E@apple.com>
	<r219-1051-i386-33DA68B7A5D04730A2C2AB4C7F70ADD2@crocodile.local>
	<597e7edb0711291550p78b29417v3bd64edd3499dd26@mail.gmail.com>
	<54CAF08F-70F5-4BDB-88C0-7653C3026F8E@apple.com>
	<52CCFC76-1D5A-4692-AC7C-4E5B6CA2A996@khiltd.com>
Message-ID: <ADEB2787-7D10-480E-8011-98C7A573A93D@apple.com>


On Nov 29, 2007, at 7:37 PM, Nathan Duran wrote:

>
> On Nov 29, 2007, at 5:14 PM, Kevin Van Vechten wrote:
>
>> Here's a summary of sessions:
>>
>> - LaunchDaemons are only loaded into the "System" session of the  
>> root launchd.  No per-user launchd has a "System" session.
>> - Unless otherwise specified by the LimitLoadToSessionType key in  
>> the plist, LaunchAgents are loaded into the "Aqua" session.
>>
>> - The "Aqua" session is the same session all GUI Applications are  
>> executed in.
>> - Logins via SSH, telnet, and others are executed in a "StandardIO"  
>> session.
>> - Each user is given a single "Background" session.  Jobs in the  
>> "Background" session may live longer than the last logout of the  
>> user.
>
> What are the odds of this information finding its way into the  
> launchctl man page?

A lot better when a bug report is filed into our tracking system. :-)

http://bugreport.apple.com/

davez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071130/13c84ddf/attachment.html