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

Re: detecting logout
by Jim Magee 09 Feb '05

09 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --Jim On Feb 7, 2005, at 5:07 PM, Pete Gontier wrote: circa 2/1/05 11:57 AM, "Pete Gontier" <pete(a)m-audio.com> 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/pete%40m-audio.com -- 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/jmagee%40apple.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 Actually (and sorry for the delay), it should be much easier than that. Simply request a Mach no-senders notification on your bootstrap service port. When there are no senders, you have no clients and can safely exit. As part of the logout process, the bootstrap namespace releases all (its) send-right references to the service ports registered in the namespace. As the user processes start to exit, any that had already looked up and held references to your service will exit as well. What results is a nice orderly shutdown (unless you have a circular dependency with another bootstrap daemon or have given your service port to something outside the login session). 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.) 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 pete(a)m-audio.com This email sent to jmagee(a)apple.com smime.p7s

1 0

Re: Catching signal errors
by Pete Gontier 09 Feb '05

09 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/8/05 1:31 PM, "Rick Steele" <wildsync(a)wildsync.com> wrote: >> In any case, the list of things one may do in a signal handler is so >> restricted that I would not attempt to generalize it up to the C++ level >> anyway. As soon as any destructor does anything as simple as call delete, Bad >> Things are likely to break loose from the ceiling and rain down around your >> ears. >> > Does this mean that a hard drive and remote network systems could blow up, or > that the computer freeze could occur? Depends on what kind of code you're writing, but in general if you are talking about signal handlers then you are talking about userland code, and so the worst likely consequence would be that your own program would misbehave in some way catastrophic to its own operation (dereference a wild pointer [and thus crash], enter an endless loop [and thus freeze], etc.). But anything is possible; your program might well become confused and write garbage into its own data files before blowing up. Depends on the program. >> As a general rule, callback functions available to C programmers should never >> allow C++ exceptions to escape. >> > I don't really understand this last sentence. How would a C callback let an > C++ exception handler "escape". Various APIs, such as the signal handling APIs, are expressed in terms of C. C++ will allow you to call C APIs, which includes passing the addresses of callback functions declared as part of those APIs, but even though a callback may be invoked as if it were a C function, if it is written in C++ then it is a C++ function. The caller doesn't know this, and isn't prepared to handle C++ exceptions which may be thrown by the callback. Consequently, a C callback written in C++ must catch all exceptions. (I often toss them into a queue for later analysis and reporting.) -- 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: kernel panics and nvram issues
by Shantonu Sen 08 Feb '05

08 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Shantonu On Feb 8, 2005, at 2:49 PM, David Osguthorpe wrote: Any ideas why nvram is not non-volatile? Is there any other command that enforces updating the nvram hardware? _______________________________________________ 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… You need to reboot successfully at least once. The kernel only syncs the nvram settings at shutdown since it has a finite number of stores. You are most likely running the nvram(8) commandline tool and not rebooting. The core dumping settings will not be honored (they are only parsed at startup) and the settings will not be preserved. This email sent to site_archiver(a)lists.apple.com

1 0

kernel panics and nvram issues
by David Osguthorpe 08 Feb '05

08 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.4.2.1i Hi, I am having problems setting up G5 cluster nodes to dump core to the head node (this relates to my previous issue with kernel panics occurring infrequently and possible interactions with hwmond) Ive setup the head node with appropriate xinetd.d entry to recieve the dumps and on a test machine using Apples InstantPanic everything works fine. The problem is that although I have set the nvram boot-args variable on all the nodes with the appropriate _panicd_ip debug flags which worked on the test machine - at least running the nvram command on the slave nodes claims this to be set up - most of the times instead of getting a core dump Im getting a panic log - not only that after the machine reboots the boot-args variable is reset to data that it had before updating with _panicd_ip etc. Another twist is that recently a circuit breaker failed cutting power instantly to a set of nodes - when power was restored and these nodes rebooted again the boot-args variable was reset and no longer contained the _panicd_ip data Any ideas why nvram is not non-volatile? Is there any other command that enforces updating the nvram hardware? Thanks David _______________________________________________ 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

APSL 2.0 vs. APSL 1.x
by David N. Williams 08 Feb '05

08 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: University of Michigan User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 I had hoped to get an at least semi-official response to the question below, so I didn't think this was quite the right place to post it. But my three attempts at more official channels failed, so here it is: I want to be sure I correctly understand the terms of the APSL as they apply to Libm 47.1 in darwin 10.3.7. APSL 2.0 states in Sec. 7 that code under earlier versions of the license may be modified and distributed under 2.0: http://www.opensource.apple.com/apsl/ The code I'm interested in is part of complex.c, which is under APSL 1.1, and does not include any statement about the validity of future versions of the license. On the other hand APSL 2.0 sits there on the Open Darwin website at the gateway for downloading the source, and claims pretty explicitly to rule. Am I correct that APSL 2.0 can indeed be used with complex.c? Thanks, David ------------------------ Earlier attempts to post: 1. From the "Contact ADC" button on the Darwin Open Source page: http://developer.apple.com/darwin/ This wound up at devseed(a)apple.com, where you get to ask questions only for money. But their reply helpfully directed me to admin(a)opensource.apple.com. 2. To admin(a)opensource.apple.com, which replied automatically asking me to include "Resend" in the subject line and try again. Upon doing so, I eventually got back a warning that the message was refused by mail-in.euro.apple.com, and after several days, a message that it really couldn't be delivered. 3. To askdarwin(a)opensource.apple.com, which was a link on the Darwin Q&A page: http://developer.apple.com/darwin/news/DarwinQA_TOC.html It immediately bounced with a notice that the user askdarwin is unknown. For future reference, maybe somebody knows where I should have posted?! _______________________________________________ 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: Catching signal errors
by Pete Gontier 08 Feb '05

08 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 I'd be surprised if this were reliable. From what I understand, one must assume a signal may occur between any two machine instructions. This is not quite the same thing as thread safety, for which there are per-thread globals and such. It's possible the C++ runtime library has been carefully engineered to tolerate this, but I'd be surprised. In any case, the list of things one may do in a signal handler is so restricted that I would not attempt to generalize it up to the C++ level anyway. As soon as any destructor does anything as simple as call delete, Bad Things are likely to break loose from the ceiling and rain down around your ears. Then there is the possibility that the signal handler caller is itself written in C++ and has its own exception stack which needs to be unwound quite independently of your own and would be skipped over if your signal handler were to throw its own exception. This is super-unlikely from a practical standpoint, but from a theoretical standpoint it may give one an idea of the sort of conflict this might create. As a general rule, callback functions available to C programmers should never allow C++ exceptions to escape. circa 2/8/05 2:27 AM, "Paul Forgey" <paulf(a)aphrodite.com> wrote: > Actually, I think you can, but I'm not sure how good an idea it really > is. Derive what you throw from std::bad_exception. At your top level > catch: > > catch (const std::bad_exception &e) > { > const char *what = e.what (); > write (2, what, strlen (what)); > // or, better yet, abort () provided you aren't catching SIGABRT for > this purpose > _exit (1); > } > > It's always bothered me that C++ exceptions aren't integrated into > system signals, but that's a very old issue. There's a "d" programming > language in development that actually addresses this. > > On Feb 7, 2005, at 9:31 PM, Rick Steele wrote: > >>> Matt Watson wrote: >>> >>>>> void fatalSigHandler(int sig, siginfo_t* info, void* context) >>>>> { >>>>> // We are very limited in what we are allowed to do in a signal >>>>> handler. // Memory should not be allocated, and most libc >>>>> functions should not be used. >>>>> static char sig_message[] = "Aborting: Fatal signal occurred!\n"; >>>>> >>>>> write(1, sig_message, sizeof(sig_message)); >>>>> exit(1); >>>>> } >>>> >>>> >>>> Never call exit() from a signal handler. You want _Exit() instead. >>>> exit() will call atexit() handlers which will are likely not >>>> signal-safe. And you probably want to use fd 2 (stderr), instead of >>>> fd 1 in the write() call. >>> >>> >>> Good suggestions. That's especially important when using dlopen or >>> NSLinkModule on libraries. They could cause further signals or even >>> signal deadlocks when they get unloaded. >>> >>>> >>>> That said: if you're not going to add any more info in your signal >>>> handler, or do any cleanup like unlink() files, it may just be best >>>> to let it crash and generate a crash log. >>> >>> >>> I assumed that he'd replace the handler with something else. >>> One of the handlers I have for a project calls execv() to restart the >>> daemon in case of a crash. That is after writing errors to a log and >>> closing open file handles/resetting signal masks (as they are both >>> inherited by the new process), and doing some other general cleanup >>> of the daemon's lock/state files. >>> >>> -Kevin- >> >> Thanks everyone!!!! >> >> I hope no one minds if I take this one step further. Is there actually >> a way to have it return to the offending code with an exception >> triggered? For example, would the following snippet work... >> >> #define kMySigError -9999 >> >> void fatalSigHandler(int sig, siginfo_t* info, void* context) >> { >> short pErr = kMySigError; >> throw(pErr); >> _Exit(1); //Not that this will ever be reached >> } >> >> main(){ >> Ptr ptrFoo = nil; >> char barrrr; >> installSignalHandler(SIGSEGV, &fatalSigHandler); >> installSignalHandler(SIGBUS, &fatalSigHandler); >> >> try{ >> barrrr = (*ptrFoo); >> }catch(short err){ >> printf("Error %x", err); >> } >> ....continue >> return(noErr); >> } >> >> Rick >> _______________________________________________ >> 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/paulf%40aphrodite.com >> >> This email sent to paulf(a)aphrodite.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/pete%40m-audio.com > > This email sent to pete(a)m-audio.com -- 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: Catching signal errors
by Paul Forgey 08 Feb '05

08 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 7, 2005, at 9:31 PM, Rick Steele wrote: Matt Watson wrote: write(1, sig_message, sizeof(sig_message)); exit(1); } Thanks everyone!!!! #define kMySigError -9999 void fatalSigHandler(int sig, siginfo_t* info, void* context) { short pErr = kMySigError; throw(pErr); _Exit(1); //Not that this will ever be reached } main(){ Ptr ptrFoo = nil; char barrrr; installSignalHandler(SIGSEGV, &fatalSigHandler); installSignalHandler(SIGBUS, &fatalSigHandler); try{ barrrr = (*ptrFoo); }catch(short err){ printf("Error %x", err); } ....continue return(noErr); } Rick _______________________________________________ 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/paulf%40aphrodite.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… Actually, I think you can, but I'm not sure how good an idea it really is. Derive what you throw from std::bad_exception. At your top level catch: catch (const std::bad_exception &e) { const char *what = e.what (); write (2, what, strlen (what)); // or, better yet, abort () provided you aren't catching SIGABRT for this purpose _exit (1); } It's always bothered me that C++ exceptions aren't integrated into system signals, but that's a very old issue. There's a "d" programming language in development that actually addresses this. void fatalSigHandler(int sig, siginfo_t* info, void* context) { // We are very limited in what we are allowed to do in a signal handler. // Memory should not be allocated, and most libc functions should not be used. static char sig_message[] = "Aborting: Fatal signal occurred!\n"; Never call exit() from a signal handler. You want _Exit() instead. exit() will call atexit() handlers which will are likely not signal-safe. And you probably want to use fd 2 (stderr), instead of fd 1 in the write() call. Good suggestions. That's especially important when using dlopen or NSLinkModule on libraries. They could cause further signals or even signal deadlocks when they get unloaded. That said: if you're not going to add any more info in your signal handler, or do any cleanup like unlink() files, it may just be best to let it crash and generate a crash log. I assumed that he'd replace the handler with something else. One of the handlers I have for a project calls execv() to restart the daemon in case of a crash. That is after writing errors to a log and closing open file handles/resetting signal masks (as they are both inherited by the new process), and doing some other general cleanup of the daemon's lock/state files. -Kevin- I hope no one minds if I take this one step further. Is there actually a way to have it return to the offending code with an exception triggered? For example, would the following snippet work... This email sent to paulf(a)aphrodite.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Catching signal errors
by Rick Steele 08 Feb '05

08 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Matt Watson wrote: write(1, sig_message, sizeof(sig_message)); exit(1); } Thanks everyone!!!! #define kMySigError -9999 void fatalSigHandler(int sig, siginfo_t* info, void* context) { short pErr = kMySigError; throw(pErr); _Exit(1); //Not that this will ever be reached } main(){ Ptr ptrFoo = nil; char barrrr; installSignalHandler(SIGSEGV, &fatalSigHandler); installSignalHandler(SIGBUS, &fatalSigHandler); try{ barrrr = (*ptrFoo); }catch(short err){ printf("Error %x", err); } ....continue return(noErr); } Rick _______________________________________________ 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… void fatalSigHandler(int sig, siginfo_t* info, void* context) { // We are very limited in what we are allowed to do in a signal handler. // Memory should not be allocated, and most libc functions should not be used. static char sig_message[] = "Aborting: Fatal signal occurred!\n"; Never call exit() from a signal handler. You want _Exit() instead. exit() will call atexit() handlers which will are likely not signal-safe. And you probably want to use fd 2 (stderr), instead of fd 1 in the write() call. Good suggestions. That's especially important when using dlopen or NSLinkModule on libraries. They could cause further signals or even signal deadlocks when they get unloaded. That said: if you're not going to add any more info in your signal handler, or do any cleanup like unlink() files, it may just be best to let it crash and generate a crash log. I assumed that he'd replace the handler with something else. One of the handlers I have for a project calls execv() to restart the daemon in case of a crash. That is after writing errors to a log and closing open file handles/resetting signal masks (as they are both inherited by the new process), and doing some other general cleanup of the daemon's lock/state files. -Kevin- I hope no one minds if I take this one step further. Is there actually a way to have it return to the offending code with an exception triggered? For example, would the following snippet work... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Apache Perl CGI environment question
by John Michael Zorko 07 Feb '05

07 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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: Apache Perl CGI environment question
by Jeff W. Boote 07 Feb '05

07 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) Hello, all ... Just use mod_env in Apache and then in the conf file: SetEnv PERL5LIB /sw/lib/perl5... jeff _______________________________________________ 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… John Michael Zorko wrote: I am sending this to both darwin-dev and darwinos-users because this question kiind of straddles the fence, me thinks. It's a simple one, though. I have some Perl code that uses the DBD::Pg (PostgreSQL DBI interface) module. This code runs fine under OSX 10.3.7 using mod_perl as long as I add this to httpd.conf: PerlSetEnv PERL5LIB /sw/lib/perl5/5.8.1/darwin-thread-multi-2level This email sent to site_archiver(a)lists.apple.com

1 0