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
> 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.
> 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
> 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