Re: Another approach to root user?
Re: Another approach to root user?
- Subject: Re: Another approach to root user?
- From: Ethan Funk <email@hidden>
- Date: Tue, 28 Mar 2006 08:29:22 -0700
First, I'll just echo what Shaun Wexler said: daemons are pretty
much forbidden from making connections to the Window Server. The
reason why is that daemons really aren't supposed to have any UI
and, as such, should have no business with the Window Server. Not
only does this mean you need to avoid frameworks like Cocoa and App
Services, but also anything that indirectly uses those frameworks
as well, like AU view code. In fact, you might even want to avoid
using stdout and stderr since these streams might point to /dev/
null depending on when launchd launces your daemon.
I am not using a GUI. In fact, I close stdin, stdout and stderr just
for good measure even though launchd does this too. I am really
trying to make a daemon here. All user control is performed through
a tcp port.
Second, I have to ask about why you need a daemon in the first
place? The task the daemon is performing will have a direct impact
on whether it should run in the root bootstrap session or in a
particular user's login session or in some other place. You might
also want to go into some detail about how outside entities
interface with the daemon (if they are supposed to).
The big picture here is of a radio automation system. A server does
all the heavy lifting (automation, playlists, audio input and file
playing, segues, logging, streaming, recording, audio output, etc). A
client application (with GUI) connects to the server via a tcp port
to control things, either on the local machine or over an network or
both. There can be any number of clients connected including zero.
Even if no one is "logged in" the server MUST keep things playing as
required by the automation setup. Running the "server" in a user
login session would work only if that session could be logged out and
the server would keep running.
From my experiments, I can login to a new user session, open the
terminal, run my server (which detaches from the terminal session via
a fork call in the non-launchd version), and log out of the user
session. My server keeps running, although the audio via HAL is
muted. The server continues to play through the files in silence.
If I log back in as that original user, the audio springs back to
life. I am assuming that the HAL is getting some sort of
notification that the user has logged out and so it mutes. Is this
correct? I assume HAL must be tied to the login session, and that is
why (I assume again) it fails to initialize under launchd. Am I on
the right track here?
By running the server as root, via sudo in the above terminal
example, I can get around things, but it sure would be nice to get
launchd to do it with out the need for a startup script with the root
password in it!
Finally, CoreMIDI is a per-user type thing. In particular, the MIDI
server itself is launched inside the user's login session. I'm not
sure what's going to happen when the MIDI server needs to be
launched outside of an actively logged in user's session. It could
work fine, but more likely it will confuse things a bit. Hopefully
Doug can clarify this for us.
I guess what I'm hearing is that I must have a user's login session
for the midi to work. I really want to have midi machine control for
starting/stopping things via hardware directly to the server, but I
guess if there is no other way, that functionality will have to be
moved to the client application.
Thanks for the help with this unusual case.
Ethan...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden