[3303] in Release_7.7_team
Re: Athena Disconnected Operation White Paper Draft 2.
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat May 25 12:51:05 2002
From: Greg Hudson <ghudson@MIT.EDU>
To: Derek Atkins <warlord@mit.edu>
Cc: source-developers@mit.edu, release-team@mit.edu
In-Reply-To: <sjmsn4hjhoe.fsf@kikki.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 25 May 2002 12:51:01 -0400
Message-Id: <1022345461.3995.77.camel@error-messages.mit.edu>
Mime-Version: 1.0
First, let me say that you're right and Thomas is wrong. Being root is
nice and all, but we certainly don't want to deal with the hair of
recreating the user context from whole cloth, particularly when it comes
to PAGs.
On Fri, 2002-05-24 at 18:37, Derek Atkins wrote:
> 1. User Network Daemon:
> Question 2: What kind of UI should it have? Should it have a GUI or
> command-line? If command-line, how do you make sure that
> it has a controlling TTY for user input?
GUI. It's not too difficult and it's the way we've been going.
(That doesn't mean the user network daemon has to have any GUI code in
it. But the scripts it runs should be expected to run programs which
pop up dialog windows, not programs which communicate with a TTY.)
> Three obvious approaches come to mind:
With all due respect, you're wasting the reader's time by presenting and
shooting down options. Just make a proposal and justify it briefly. In
this case, your proposal is:
> 3) Use a "status daemon". Create a "network status daemon" which
> sits between the network scripts and the user network daemons.
> This daemon can have a well-known PID (because there is only one
> per system), so the network scripts can signal this daemon
> directly. The user network daemons connect to the status daemon
> via a well-known unix-domain socket.
This seems reasonable, as long as the IPC code involved is kept to a
minimum level of complexity.
> 3. Scripts
If you aren't aware of it, Red Hat already has some directories full of
scripts which get executed in a user context. /etc/profile.d is the
obvious example. Just so you know that there's precedent to look at.
> 3) One script per service. Each service has a single script that
> handles all four states. This is exactly how init scripts work.
> As you add new services, you just add new scripts.
This is probably the way. (Perhaps not the way I would have chosen if
there were no precedent, but given that /etc/init.d is the way it is, we
shouldn't be gratuitously inconsistent.) (4) would also work, of
course, if there's a good argument for it being more consistent with
other things (ifup/ifdown scripts?).
> The other open issue regarding scripts is how users can override or
> control the actions of global scripts?
This is secondary functionality. I wouldn't even worry about it for the
first revision. Power users who don't like what our daemon does can
simply arrange not to run it.
