February 2005 - Darwin-dev - lists.apple.com

Re: detecting logout
by Pete Gontier 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.6.040913.0 circa 2/1/05 2:14 PM, "Paul Nelson" <nelson(a)thursby.com> wrote: >> 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. > Look for documentation for > SCDynamicStoreKeyCreateConsoleUser > and > SCDynamicStoreSetNotificationKeys > > You should get a notification whenever any user logs out of the "console" > (anyone logged in with fast user switching too). Your code will have to > figure out who logged out. You're referring to what's documented in QA1133, which as I explained has proven inadequate. However, I did just think of an algorithm which involves counting the processes which belong to the current user and quitting if there is only one after asserting that it is me, but that seems quite roundabout and indirect and may create a race with the user logging in again. I will have to give it some consideration. circa 2/1/05 2:14 PM, "Jerry Pendergraft" <jerry(a)endocardial.com> wrote: > Even though you can't reasonably modify each users login script you should > be able to modify /etc/profile which is run by all logins - I think that > includes ssh sessions. I don't think it's a good idea for shrink-wrap software to modify said file. circa 2/1/05 2:21 PM, "Chad Jones" <ctj951(a)yahoo.com> wrote: > ...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. ;-) Have done. -- Pete Gontier http://www.m-audio.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: detecting logout
by Chad Jones 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Pete, 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. http://developer.apple.com/qa/qa2001/qa1133.html 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 (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net This email sent to markie(a)ydl.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net This email sent to markie(a)ydl.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/ctj951%40yahoo.com This email sent to ctj951(a)yahoo.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. ;-) 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. This email sent to site_archiver(a)lists.apple.com

1 0

Re: detecting logout
by Jerry Pendergraft 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com This idea assumes your users are defined with /bin/sh or /bin/bash as their login shell. Since they don't do anything with command line they should not care anyway. Even though you can't reasonably modify each users login script you should be able to modify /etc/profile which is run by all logins - I think that includes ssh sessions. You fire up your daemon in /etc/profile after setting a "trap" to stop it. trap EXIT "your-kill-command" your-start-up-command Then on logout (aka exit from the shell) your daemon should be killed. -- Jerry Pendergraft jerry.pendergraft(a)endocardial.com Endocardial Solutions voice: 651-523-6935 1350 Energy Lane, Suite 110 fax: 651-644-7897 St Paul, MN 55108-5254 mobile: 651-491-0163 On Tue, 1 Feb 2005, Pete Gontier wrote: > By the way, the triple-posting of my original message didn't come from me. > According to the headers of the duplicates, someone else re-sent my message > twice. I guess we'll see if it happens again for this message. :-) > > circa 2/1/05 12:16 PM, "Graham J Lee" <leeg(a)teaching.physics.ox.ac.uk> > wrote: > > > Does the user's .logout script (or whatever alternative bash has) get > > run when they log out of the console environment? If so, you launch > > your daemon from .login, and cause it to write its pid into > > ~/.mydaemonname.pid, and then .logout contains the line "kill -QUIT > > `cat ~/.mydaemonname.pid`". > > If this script does run, and I doubt it does since typically such things are > only run as part of a terminal session, I can't really exploit this > reasonably because such scripts are arbitrarily complex and thus very > difficult to reliably modify programmatically (especially on uninstall), and > our users have no command-line expertise so can't do it themselves. > > > Of course, if it doesn't get run, then you probably need to use a > > logouthook. But that would make you a customer of the WindowServer, > > which you don't want (understandably, because then users who ssh in > > don't get to kill their daemons). > > I got an additional message off-list containing a link to a page on logout > hooks. > > http://developer.apple.com/documentation/ > MacOSX/Conceptual/BPSystemStartup/Tasks/CustomLogin.html > > I read this far and stopped: > > you must modify the code for launching loginwindow found in /etc/ttys > > Wow. I am definitely not in a position to do that. > > I suppose I should consider kAEQuitApplication, but I am not sure how I am > going to listen to that without attaching to the window server. I have heard > there are lower-level ways to do Apple events, but I have never used them. > > -- > > Pete Gontier > http://www.m-audio.com/ > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/jerry%40endocardial.com > > This email sent to jerry(a)endocardial.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: detecting logout
by Paul Nelson 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 Look for documentation for SCDynamicStoreKeyCreateConsoleUser and SCDynamicStoreSetNotificationKeys You should get a notification whenever any user logs out of the "console" (anyone logged in with fast user switching too). Your code will have to figure out who logged out. > From: Pete Gontier <pete(a)m-audio.com> > Date: Tue, 01 Feb 2005 11:57:17 -0800 > To: <darwin-dev(a)lists.apple.com> > Subject: detecting logout > Resent-From: Mark Jaffe <markie(a)ydl.net> > Resent-Date: Tue, 1 Feb 2005 12:35:03 -0800 > > 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 (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net > > This email sent to markie(a)ydl.net > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net > > This email sent to markie(a)ydl.net > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/nelson%40thursby.com > > This email sent to nelson(a)thursby.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: detecting logout
by Pete Gontier 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.6.040913.0 By the way, the triple-posting of my original message didn't come from me. According to the headers of the duplicates, someone else re-sent my message twice. I guess we'll see if it happens again for this message. :-) circa 2/1/05 12:16 PM, "Graham J Lee" <leeg(a)teaching.physics.ox.ac.uk> wrote: > Does the user's .logout script (or whatever alternative bash has) get > run when they log out of the console environment? If so, you launch > your daemon from .login, and cause it to write its pid into > ~/.mydaemonname.pid, and then .logout contains the line "kill -QUIT > `cat ~/.mydaemonname.pid`". If this script does run, and I doubt it does since typically such things are only run as part of a terminal session, I can't really exploit this reasonably because such scripts are arbitrarily complex and thus very difficult to reliably modify programmatically (especially on uninstall), and our users have no command-line expertise so can't do it themselves. > Of course, if it doesn't get run, then you probably need to use a > logouthook. But that would make you a customer of the WindowServer, > which you don't want (understandably, because then users who ssh in > don't get to kill their daemons). I got an additional message off-list containing a link to a page on logout hooks. http://developer.apple.com/documentation/ MacOSX/Conceptual/BPSystemStartup/Tasks/CustomLogin.html I read this far and stopped: you must modify the code for launching loginwindow found in /etc/ttys Wow. I am definitely not in a position to do that. I suppose I should consider kAEQuitApplication, but I am not sure how I am going to listen to that without attaching to the window server. I have heard there are lower-level ways to do Apple events, but I have never used them. -- Pete Gontier http://www.m-audio.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: detecting logout
by Graham J Lee 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 1 Feb 2005, at 19:57, Pete Gontier wrote: Just thinking out loud...my IDE is Mail.app and all that. Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. Does the user's .logout script (or whatever alternative bash has) get run when they log out of the console environment? If so, you launch your daemon from .login, and cause it to write its pid into ~/.mydaemonname.pid, and then .logout contains the line "kill -QUIT `cat ~/.mydaemonname.pid`". Of course, if it doesn't get run, then you probably need to use a logouthook. But that would make you a customer of the WindowServer, which you don't want (understandably, because then users who ssh in don't get to kill their daemons). This email sent to site_archiver(a)lists.apple.com

1 0

detecting logout
by Pete Gontier 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.6.040913.0 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 (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

detecting logout
by Pete Gontier 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Resent-date: Tue, 1 Feb 2005 12:35:03 -0800 Resent-from: Mark Jaffe <markie(a)ydl.net> Resent-message-id: <23f2f0bbb5c832190d411e3bc1d2a433(a)m-audio.com> 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. http://developer.apple.com/qa/qa2001/qa1133.html 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 (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net This email sent to markie(a)ydl.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net This email sent to markie(a)ydl.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. This email sent to site_archiver(a)lists.apple.com

1 0

detecting logout
by Pete Gontier 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Resent-date: Tue, 1 Feb 2005 12:10:12 -0800 Resent-from: Mark Jaffe <markie(a)ydl.net> Resent-message-id: <BE251F1D.259D%pete(a)m-audio.com> 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. http://developer.apple.com/qa/qa2001/qa1133.html 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 (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/markie%40ydl.net This email sent to markie(a)ydl.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. This email sent to site_archiver(a)lists.apple.com

1 0

Re: IOATABlockStorage-131.3.2
by Felix Kronlage 01 Feb '05

01 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 1, 2005, at 10:17, Markus Hitter wrote: - -fkr [1] <url: http://darwinsource.opendarwin.org/> - -- 076E 1E87 3E05 1C7F B1A0 8A48 0D31 9BD3 D9AC 74D0 http://fkr.hazardous.org/ | http://opendarwin.org/~fkr/ | FKR-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB/1isDTGb09msdNARAooOAJ4oxwSFyO9tmSg6FRtzHTF1HifA/ACeNj8N NhTQnhE6U+lfZ2xmnEWqbHI= =VJ2U -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… so ... what should i do to get access to those sources ASAP? There used to be anonymous CVS access at opendarwin.org as well as at some apple site (opendarwin.apple.com?). Both require APSL agreement (ADC Online membership, btw.), however. As long as the sources are not posted by Apple, we won't have them either. Furthermore I'd like to point at the darwinsources-Site[1]. Where we mirror the sources from the Apple-site (but of course, we only have what Apple posted). This email sent to site_archiver(a)lists.apple.com

1 0