Re: Launch a user-process from daemon
Re: Launch a user-process from daemon
- Subject: Re: Launch a user-process from daemon
- From: Rakesh Singhal <email@hidden>
- Date: Wed, 21 Jan 2009 23:29:22 +0530
I want to launch a GUI from daemon, when it gets device plugged-in
notification. I observed following things while working on 10.4.11 ppc
and 10.5.4 intel:
1. The daemon launches the GUI on 10.4.11 ppc when I start the system.
Now if I log out and logs in and plug-in device again then it gives
error -10810. I could not understand that why does this error come and
how to resolve this.
2. If I first log in as root user and daemon launches the GUI. Now I
close the GUI and switch to another user. Now if daemon launches the
GUI then it gets launched in root user, not in current user. It shows
same behaviour with all users.
Please advice me to solve these.
Thanks in advance.
Regards
rksinghal
On Thu, Jan 15, 2009 at 8:26 AM, Rakesh Singhal
<email@hidden> wrote:
> Hi Jason,
>
> Thanks a lot. I have two applications, daemon application and GUI.
> Constraints:
> First constraint is daemon launches GUI whenever it requires. Daemon
> checks for a particular USB device and then it launches the GUI. If at
> boot time, device is already plugged-in then it will launch GUI in
> starting only.
> Second I can not make changes in GUI code, it will be launched by
> daemon application.
>
> If I use daemon as an agent then it is able to launch GUI, but I can
> not use my daemon application as an agents cause I want two things:
> 1. Only one daemon for all logins.
> 2. I do not want system to close daemon application, when any user logs out.
>
> Regards
> rksinghal
>
> On Wed, Jan 14, 2009 at 11:09 PM, Jason Coco <email@hidden> wrote:
>>
>> 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