launchd question

[Christopher Hunt]

Really, the last update this time. :-)

I managed to re-direct the output of stderr to a file via launchd  
(very option that one):

2007-02-28 22:38:10.503 osascript[9069] CFLog (0): CFMessagePort:  
bootstrap_register(): failed 1100 (0x44c), port = 0x2103, name =  
'Processes-0.35782657'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2007-02-28 22:38:10.511 osascript[9069] CFLog (99):  
CFMessagePortCreateLocal(): failed to name Mach port  
(Processes-0.35782657)
CFMessagePortCreateLocal failed (name = Processes-0.35782657 error = 0)

The error code 1100 equates to BOOTSTRAP_NOT_PRIVILEGED. This is all  
that I could find on this error:

***
A deactivated bootstrap namespace allows you to look up services, but  
it does not allow you to register new services. Any attempt to  
register a service in a deactivate namespace will fail with an error  
BOOTSTRAP_NOT_PRIVILEGED (1100). Similarly, any high-level wrapper  
that registers a service will fail. For example,  
CFMessagePortCreateLocal will print an error message and return NULL  
if you call it after your namespace has been deactivated.
***

Any ideas?

Cheers,
-C

On 28/02/2007, at 10:04 PM, Christopher Hunt wrote:

> Latest update: I think that my problem has something to do with  
> either the sequence of when Finder is launched and/or whether  
> Finder is even present. I didn't think it important to mention that  
> the user B account is also a kiosk style of account i.e. a custom  
> application is launched in place of Finder. Perhaps this is causing  
> the problem...
>
> Oh well... I've had to resort back to cron as my scheduled  
> osascript command worked just fine there. I would like to get  
> launchd working for me though so please keep coming through with  
> any other ideas.
>
> Cheers,
> -C
>
> On 28/02/2007, at 8:26 PM, Christopher Hunt wrote:
>
>> I've just made a discovery that I think is worth sharing.
>>
>> Firstly I have a user that can administer the computer (user A)  
>> and one that can't (user B). If I issue a launchctl start from the  
>> command line for user A then the osascript -e <command> works! Of  
>> course this is not the case for user B.
>>
>> However if I perform a "launchd bash", load the plists and the  
>> perform the launchctl start (all for user B)s then all is well!
>>
>> I'm confused... if things work under launchd bash then why  
>> shouldn't they outside of that shell?