Re: Detecting login/logout?
Re: Detecting login/logout?
- Subject: Re: Detecting login/logout?
- From: Wade Tregaskis <email@hidden>
- Date: Sat, 1 Nov 2003 22:59:03 +1100
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.
Just to clarify, this will kill any apps in the user's context,
right... so apps that were started at boot time (prior to the
loginwindow process) - and magically survived the login - won't be
killed, right?
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.
Yes, I'm rather aware of that. :)
Just out of curiosity, not for any specific reason, does the window
server first send a catchable signal? If not, how are programs
expected to shut down gracefully?
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?
The process is an execution and management daemon for a distributed
processing system. At present, I'm just running it manually in my own
login space, since I'm doing the whole run-debug-fix-build-repeat
cycle, but I'll soon want to test it in it's final configuration.
The problem with quitting the daemon between logins and logouts is that
the cost of establishing and configuring the networking is rather high,
not to mention the inconvenience of having to shut down any executing
tasks and transport them to another machine, etc.
Also, I'd like to be able to run code while the login window is up, so
the software can be used in labs where there may not be anyone around.
Plus, the daemon also communicates with local clients to organise task
execution (on other computers), and I'd like to be able to serve
multiple users simultaneously.
Finally, everything needs to go through the single instance of the
daemon for networking and security reasons - I can quite well defend
this, although I loathe to have to write up all the details, so please
take my word for it.
I don't see why this isn't possible - after all, there's at least a
dozen Unix daemons that run from startup to shutdown, irrelevant of UI
operations and other user activity. I don't see httpd or sshd being
killed just because a user logs in or out... indeed, that would be very
bad, I imagine.
(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.
Sorry, we've gotten our wires crossed - this was the "existing context"
I meant, the "root context" as you've called it. To get things
straight, this is where I want my app to live. I'm taking from your
response that the behaviour I'm hoping for is actually what I'm going
to get, aside from any mach/UI issues.
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.
This seems like it's going to be the painful part... I'm using several
"high level" frameworks - Security, Foundation, etc. Not AppKit; the
app doesn't want to have a UI of any sort, not even at a terminal...
but I seem to remember from a previous thread somewhere that the
Security framework links to the window server. Is this true, and still
true in Panther?
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.
Ah, this is better news in my case. Is there any
documentation/examples handy on what these hoops and magic are?
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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.