Re: detecting logout
Re: detecting logout
- Subject: Re: detecting logout
- From: Jim Magee <email@hidden>
- Date: Tue, 8 Feb 2005 20:44:04 -0500
Actually (and sorry for the delay), it should be much easier than that.
Simply request a Mach no-senders notification on your bootstrap
service port. When there are no senders, you have no clients and can
safely exit. As part of the logout process, the bootstrap namespace
releases all (its) send-right references to the service ports
registered in the namespace. As the user processes start to exit, any
that had already looked up and held references to your service will
exit as well.
What results is a nice orderly shutdown (unless you have a circular
dependency with another bootstrap daemon or have given your service
port to something outside the login session).
--Jim
On Feb 7, 2005, at 5:07 PM, Pete Gontier wrote:
After much tearing of hair and gnashing of teeth, it looks like the
solution
for me involves calling SessionGetInfo (to determine whether the
current
session is potentially a GUI session) and
CGSessionCopyCurrentDictionary (to
determine whether the current session is actually a GUI session). My
code
assumes that any potential GUI session which stops being an actual GUI
session has been "logged out" of the console. Whenever the console
user
changes and the current session is not an actual GUI session, I quit.
This
may not be perfect, so feedback is welcome. (Happily, I don't have to
worry
about SSH logins [and doing so would thus be undesirable] because
that would
not be useful for this particular porgram.)
circa 2/1/05 11:57 AM, "Pete Gontier" <email@hidden> wrote:
This may be a Mac OS X question as opposed to a Darwin question.
Nevertheless, this is the only relevant place I know of to ask this
question.
I am developing a per-user bootstrap daemon. This program used to be
a
startup item, but for obscure reasons not relevant to the problem at
hand,
it became necessary to morph it into a per-user bootstrap daemon
(and not,
it should be noted, a global bootstrap daemon). The key difference
between
the two forms of program for purposes of this discussion is that a
startup
item launches once at startup and a per-user bootstrap daemon
launches
whenever a user logs in. This means that there may be many instances
of a
single per-user bootstrap daemon, which is fine. The trick is
knowing when
each instance should quit. When the user logs out, per-user bootstrap
daemons are not automagically killed, which I suppose may be a
feature to
someone somewhere. For me, it presents a problem, because there is
no reason
for an instance of my program to hang around after the user logs
out. The
trick is knowing when that is.
Apple's QA1133 seems to be the available wisdom on knowing when
users login
and logout.
http://developer.apple.com/qa/qa2001/qa1133.html
Unfortunately, this QA seems to be out of date. It seems to describe
the
pre-Panther, pre-Fast User Switching universe. QA1133 tells us we
are to
believe the user is logging out when the user name is NULL, but,
under
Panther, if user 1 logs in, user 2 logs in, and then user 2 logs
out, at no
time will the console user be NULL. Even when the user is
re-authenticating
to switch back to user 1, the console user is "loginwindow" as
opposed to
NULL. (The user may be NULL after the *last* user logs out, but I
haven't
tested this.)
I could enable the copious debug logging done by the distributed
notification server and maybe pick out some choice undocumented
strings as
they fly around in the system and hope to interpret their meaning
correctly,
but that seems unlikely to be future-proof.
If I must resort to higher-level APIs, I'd prefer Carbon-oriented
solutions
rather than Cocoa-oriented solutions because the app in question is
written
in C++, but I'll settle in a pinch for anything that works cleanly
without
pulling me up into being a client of the window server.
Any ideas?
--
Pete Gontier
http://www.m-audio.com/
_______________________________________________
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
--
Pete Gontier
http://www.m-audio.com/
_______________________________________________
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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