Re: Detecting login/logout?
Re: Detecting login/logout?
- Subject: Re: Detecting login/logout?
- From: Chad Jones <email@hidden>
- Date: Sat, 1 Nov 2003 02:41:44 -0800
Hi Everyone,
I'll try to put all my responses to this tread in one message:
-----------#1
Detecting login/logout?
You can detect login/logout using the QA I posted here:
http://developer.apple.com/qa/qa2001/qa1133.html
Note the QA at the moment isn't compatible Panther (due to changes
relating to fast user switching).
The QA will be updated for Panther when I get the chance. Sorry for
the delay in the update but things are chaos at the moment.
-----------#2
It may not work, but you could try checking the owner of the
loginwindow or WindowServer processes. When logged in they're owned by
the logged in user... presumably at the login screen they are owned by
root, or some other generic account.
This technique works on some Mac OS X systems but not others. The
recommended solution is to use the techniques detailed in the QA listed
above.
-----------#3
I've been asked to look at the feasibility of writing a utility that
needs to run _alongside_ the login dialog on OS X.
What problem exactly are you trying to solve? Why does the GUI have to
show up at the login screen and no other time? Also, what Mac OS X
system(s) are you targeting?
-----------#4
One thing you could look at are these two distributed notifications.
[[NSDistributedNotificationCenter defaultCenter] addObserver:
self selector: @selector(didMoveOffConsole:) name:
@"com.apple.sessionDidMoveOffConsole" object: nil];
These are Panther-only notifications which are sent when a Fast User
Switch occurs...
-----------#5
However, there are some issues with your application being terminated
with the login session that you might need to look at.
Yep. After a logout your application by default will get terminated
(actually killed) by the system. I won't go into why, lets just say it
has to do with a security model/feature inherited from NeXT.
-----------#6
Any idea off hand how the program is terminated? i.e. is it just a
signal that can be caught?
Your application will be sent a SIGKILL from WindowServer. SIGKILL is
a signal which can't be caught.
-----------#7
I'm looking at doing a similar thing with a
process that needs to run from startup through login/logout cycles. I
cannot rely on individual accounts to have my process set as a login
item, nor would it be convenient to have to handle the closing and
reopening of my process.
If your program is running as an administrator you can set LoginItems
to launch for _all_ users on the system. The LoginItems will run for
all users from the time they login to the time they logout. Using this
technique may this particular problem. If you send an email to
email@hidden requesting the "LoginItemAPI" sample I explain in the
sample code how to install LoginItems for all users. You will not be
charged a DTS incident to get the sample.
If the above doesn't solve this particular problem and if your process
also needs to run at logout time (and not just when users are logged
in) can you explain why?
-----------#8
(2) Programs that are launched via the StartupItems mechanism are in a
different Mach bootstrap context than normal processes. When the user
logs in, your program will be killed, because it has created Mach
ports (by linking and using certain CoreFoundation functions) and
those ports will be stale when the new Mach context is brought >
forward.
Are you sure the existing context is destroyed? How do normal programs
(e.g. system daemons) survive?
The login context is created when the user logs in and is destroyed
when the user logs out. How system daemons survive is they live in a
separate context (the "startup context" a.k.a. "root context" ) which
exists from first startup until the system is shut off.
Note processes in the startup context can't/shouldn't use higher level
frameworks (e.g. Carbon/Cocoa) or risk being killed by the operating
system for reasons I won't go into detail. Let's just say that the
higher-level frameworks sometimes need to talk to certain parts of the
operating system which are only available to user/login sessions. If
the frameworks finds it can't talk to those parts then the framework
will call abort() on the calling process which in the end puts up the
"unexpectedly quit" dialog to the user.
--------#9
I was under the impression that you
just couldn't communicate (with mach ports) between login processes and
user processes.
It is possible to communicate with mach ports if you jump through some
hoops. With some magic a process in the startup context (mentioned
above) can communicate with processes in the user context and visa
versa. However, processes in different user contexts can not
communicate directly with each other. If they need to communicate they
need to do so through the middle man in the startup session.
I'll see what I can do to answer further questions. However, if it
gets too involved I'll have to ask the party to submit a DTS incident
via email@hidden (I am a member of Apple DTS).
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.