Re: detecting logout
Re: detecting logout
- Subject: Re: detecting logout
- From: Chad Jones <email@hidden>
- Date: Tue, 1 Feb 2005 16:21:18 -0600
Hi Pete,
Are you using SystemLoginItems to solve this problem? SystemLoginItems
of course being rather radically different from "regular" LoginItems as
they run as root. Are launched on a per user basis (including FUS
users) but launched *before* the user actually logs in (actually
launched when Window Server creates a new session, just after
loginwindow is launched for that user). Also the process has full
access to the window server which can be handy.
If you are using a SystemLoginItem then I don't really see the problem.
You should be terminated as a regular part of the logout for that
user. Just use the usual process termination mechanisms at logout
outlined in SystemOverview:
http://developer.apple.com/documentation/MacOSX/Conceptual/
BPSystemStartup/index.html.
If you aren't using SystemLoginItems perhaps you should consider their
use. I think your problem would be very hard to solve cleanly without
them. SystemLoginItems were created in 10.3.0 just after the creation
of Fast User Switching (and associated developer problems) made
necessary a new mechanism to solve those problems. :-)
Note I don't see any documentation on the developer site for
SystemLoginItems. :-(
However, I know if you email Apple DTS they can send you some
documentation I worked on just before leaving there. That is if you
ask for the document by name: Technote 2077 (Fast User Switching
technote). The document wasn't completely done at my departure.
However, it includes full sample code and documentation on
SystemLoginItems and their use, along with description of other
mechanisms you might be interested in. ;-)
Also, glad you like my old QA1133 (first one I ever published). ;-)
On Feb 1, 2005, at 1:57 PM, Pete Gontier 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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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