[launchd-dev] Diagnosing launchd daemon failure to launch

[Ned Hogan]

Sorry, I did make myself clear,  I have two processes, one that runs  
as a damon in the background and should remain persistent, and another  
that is valid only in the aqua context.

The first is a traditional UNIX style daemon, called AgentMon, that is  
a client to a Server in the Cloud that runs in the background as root,  
all of this code was orginally based on the inetd or xinetd model,  
similar to rshd or sshd daemon. It's been cleaned up to not do fork  
children via the tech note.

It in turn communicates with a second local user agent, UsrTask, that  
is launched via a login hook (loginwindow.plist).

We can but don't support FUS, so one and only one UsrTask to represent  
the user along with one and only one the AgentMon to represent the  
system. This again complicates things as far as simply having it  
launch in the aqua context, but I should be able to use ~/Library  
verses /Library

The user has the option to quit the UsrTask, the daemon should stay  
alive in most but not all cases.

In the case that AgentMon also needs to exit, I could handle this by  
having the daemon remove the QueueDirectory toggle file, and then have  
the LaunchAgent exit. Touch the queue to relaunch.

The QueueDirecotry makes sense for AgentMon, and I am happy with the  
way this works. The question is should I make the QueueDirectories the  
Domain Socket for UsrTask? This thread now makes me ponder if I should  
be using the Sockets method instead.

Hopefully this makes sense, just looking for some advice, but I am  
sure I can figure it out one way or another.


On Nov 7, 2008, at 10:57 AM, Damien Sorresso wrote:

> On Nov 7, 2008, at 7:13 AM, Ned Hogan wrote:
>> I am confused, I thought the purpose of setting the sticky bit on / 
>> var/tmp was so you could count on your files being persistent  
>> there? What comes along and cleans out this directory?
>
> D'oh! I was thinking of /private/tmp, not /var/tmp. Sorry.
>
>> This is not to say your suggestion to to move to /var/run is not  
>> valid, but the code I inherited uses /var/tmp based on the security  
>> concerns at the time.
>>
>> The daemon, now best described as a LaunchAgent on Leopard that is  
>> in production I want to move to the launchd model from it's current  
>> StartupItems implementation. However I am not quite clear on how to  
>> let the domain socket listener know that I have been killed and  
>> restarted, is it my job to kill off the listener and restart, or  
>> could I create another another launchd task to watch for the  
>> creation of a new domain socket and would cause the listener to  
>> reconnect? For security reasons you do want to create a new domain  
>> socket, right?
>
> No. In the launchd model, launchd will hold a file descriptor for  
> the Unix domain socket and listen on it. When data are available,  
> launchd will start your agent up. Your agent will then check in with  
> launchd and obtain the file descriptor and start reading from it. If  
> your agent dies when there is still unread data on the socket, it'll  
> be started back up, and you can pick up where you left off in the  
> stream.
>
> Let launchd worry about the socket. All your agent needs to know is  
> that it was launched because there are data on the socket that need  
> to be read.
>
>> In testing I have also noticed that I can loop when launched, how  
>> would I set a limit or a backoff with a runaway launchd process?
>
>
> See launchd.plist(5), specifically, the KeepAlive criteria.
> -- 
> Damien Sorresso
> BSD Engineering
> Apple Inc.
>