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: Thu, 9 Apr 2009 09:30:27 PDT
- Comments: In-reply-to Michael Smith <email@hidden> message dated "Thu, 09 Apr 2009 09:01:39 -0700."
Michael Smith <email@hidden> wrote:
>
> On Apr 8, 2009, at 4:50 PM, Bill Janssen wrote:
>
> > The only way to do this in Leopard seems to be with launchd, which
> > seems
> > to do the right thing. The main problem with using launchd here is
> > that
> > users cannot manipulate their own server; you can either use a root
> > LaunchDaemon which only root can unload, or a user LaunchDaemon
> > which is
> > again fatally bound to the login bootstrap context.
>
> 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.
"restart" is easy; I just have a LaunchDaemon that specifies
RunOnLoad=true, UserName=foo, KeepAlive=true. So if the user kills it
(with SIGTERM, say, which a non-root user can send to the daemon
process, and the daemon can handle) it just gets restarted by launchd.
Assuming I set the ThrottleInterval and ExitTimeOut properly, it should
be fine.
It's "stop" (and "start") that bugs me. I essentially need to do a
"launchctl unload -w" as root to do this. Otherwise the KeepAlive kicks
in and it's running again before you can say, "Aw, shucks". And I need
to be able to do this with a non-admin user. Same thinking for "start".
Terry pointed out that I could always write *another* daemon that ran as
root in the startup context and just responded to requests to manage my
first daemon. Yes, I could, but launchd is just sitting there...
Perhaps the simplest change would be to allow non-root launchctl
invocations to control (unload -w) daemons running with a UserName
equivalent to the euid of the invoking process, provided the plist file
is also owned by that uid.
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