Re: Launch a user-process from daemon
Re: Launch a user-process from daemon
- Subject: Re: Launch a user-process from daemon
- From: Jason Coco <email@hidden>
- Date: Wed, 14 Jan 2009 12:39:52 -0500
On Jan 14, 2009, at 12:22 , Rakesh Singhal wrote:
I have to read it completely but I would like to let you know that if
I use LaunchAgents then my GUI is getting launch through daemon
application. BUt I want to keep the daemon in LaunchDaemons and then I
want to launch my GUI using daemon.
If this is what you want, you have to design it for this. Don't try
and make your
daemon launch a GUI. Instead, design two parts, the daemon and the
GUI. Decide
how you want them to communicate. You can use distributed objects in
Cocoa, you
could use a UD socket, you could use an IP socket... the choice is
yours.
Create the daemon and install it in /Library/LaunchDaemons. Have it
listen
using whatever mechanism you decide on (UD socket, DO, heck, mach port
even),
then install the GUI part in your user's LaunchAgents section. When
the user logs on,
the GUI will be launched by launchd and can then connect to the daemon
and
let it know that it just came up/get further instructions/whatever.
That said, you should probably have a very good reason for doing this.
Generally,
when I create a daemon for some service and I want to have a GUI to
interact with
it, I /always/ let the user decide when to start and stop that GUI.
For instance, I have
written a daemon that controls a mail service. It comes up in the root
namespace and
is installed under /Library/LaunchDaemons/. It listens for management
information
on a UD socket. It uses the security framework to ensure that any user
has been
granted the system.privilege.admin right before it will respond at all.
I then have a system panel plugin that does basic configuration. The
system
panel connects over the UD socket and provides information like
whether the
services is started/stopped... provides a button to recycle/stop/start
the service
and provides basic configuration information (start at launch, IP
bindings, etc.).
Finally there is a full GUI application. This GUI can do everything
that the system
panel can do, plus it will do real-time monitoring, allow performance
tweaks and
adjustments, and do a number of other things that don't make sense in
the context
of the system panel plugin. The GUI also communicates over the same UD
socket.
Using this design, I could easily create a text-only interface, a web
interface, or any
other number of interfaces. If I felt there was a need for remote
configuration (right
now there's a requirement /against/ that), I could add an IP socket as
well (of course,
this would then require some kind of distributed authorization to be
added, but I digress).
Basically, Rakesh, you have to look at your problem, look at the
constraints, and look
at the users and come up with a viable solution... then start coding.
That is just
as important as writing code. In this case, Mac users generally don't
want all kinds
of stupid GUI applications popping up when they start their computer.
That is more
of a Windows thing... and most Windows users I know hate this as well
(they just
accept it more readily because before NT 3.51 there really was no
service mechanism
for applications to use)... and of course, since NT 3.51 many
programmers have been
too lazy to write proper services so the design anti-pattern continues
(although, to
be fair, this is changing).
If you have some background process that needs to run in the context
of a user, however,
from the time they log in, you could still use this approach. You
write the daemon and
use a UD socket for communication. You then write a background-only
LaunchAgent
that does whatever it needs to do and (for simplicity) maybe exposes a
couple of DOs. Then
the control panel and/or full GUI could interact with the LaunchAgent
instead of with
the daemon directly. This still lets you do any per-user background
processing that
you might want to do AND lets the user decide whether she wants to
launch a GUI
process.
Anyway, I hope this helps you. Jason
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden