Re: testing the current bootstrap context?
Re: testing the current bootstrap context?
- Subject: Re: testing the current bootstrap context?
- From: Bill Janssen <email@hidden>
- Date: Fri, 10 Apr 2009 12:40:56 PDT
- Comments: In-reply-to Terry Lambert <email@hidden> message dated "Fri, 10 Apr 2009 12:17:36 -0700."
Terry Lambert <email@hidden> wrote:
> On Apr 10, 2009, at 11:55 AM, Bill Janssen <email@hidden> wrote:
> > Terry Lambert <email@hidden> wrote:
> >
> >> On Apr 10, 2009, at 9:31 AM, Bill Janssen <email@hidden> wrote:
> >>> Michael Smith <email@hidden> wrote:
> >>>> On Apr 9, 2009, at 9:30 AM, Bill Janssen wrote:
> >>>>> Michael Smith <email@hidden> wrote:
> >>>>>> It's usually straightforward for the daemon to vend the
> >>>>>> appropriate
> >>>>>> self-manipulation functionality; frequently you want to gate this
> >>>>>> with
> >>>>>> application-specific logic anyway.
> >>>>>
> >>>>> Well, the daemon does a lot of things, but what I'm concerned with
> >>>>> is
> >>>>> stop, start, and restart.
> >>>>
> >>>> Why do you need 'stop'? Why can't you just ask the daemon to
> >>>> enter a
> >>>> state where it refuses requests?
> >>>
> >>> Because I want to fix it with new code.
> >>
> >> So just fix it and tell it to exit.
> >>
> >> When a process exits and launchd restarts it, launchd doesn't know if
> >> it's running old code or new code when it's relaunched, it just knows
> >> its path.
> >
> > Sure, but the old code does bad things on exit (like saving state in
> > an
> > invalid format). I'm pretty sure I need, in the general case, to be
> > able to stop it, fix things, and restart it.
>
> Support a command to exit without saving state before your first
> deployment.
Wow, this is getting tortuous.
> Robust systems self-heal rather than requiring an external agency. Why
> do you need it stopped while you fix things externally, rather than
> having a check to see if things need to be fixed be the first thing
> you do when you restart, and self-heal?
Sure, we do that when we can. But my scenario is that I'm on the phone
with a newbie user on the other side of the country, and something's
going wrong. I ask them to stop their server, edit a config file that's
written on shutdown by the server, and start their server again.
> If nothing else, instead of installing the binary for your process,
> install the binary for the fix process instead, and have the last
> thing it does as it fixes things is replace its binary and exit.
>
> We intentionally erected a protection domain barrier here, where
> processes that do what your process wants to do have to ask permission
> to perform privileged operations, or at least politely request those
> privileged operations be performed on their behalf.
And, as an OS X user and developer, let me take this opportunity to
thank you for it.
But I wonder if you're not mischaracterizing one or two operations as
"privileged". Stopping a daemon that runs as the user shouldn't be
privileged (IMO), but I'd be happy to hear the security analysis that
persuaded you guys otherwise.
And I still wonder if setsid() shouldn't take care of this case (on OS X).
> Your code needs to Roth ask politely like everyone else, or run as root.
"Roth ask"? There's no need to run it as root, and I'm not going to do
that. But I think there is a need to better support management of user
daemons that run even when the user is logged out.
Bill
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden