Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
[Long email, some comments, some ideas. It's not *quite* rambling enough to split into separate social and technical responses.] > From: Tony Hoyle [mailto:tmh at nodomain.org] > It'll keep runnning regardless - each client gets their own process. Sure. But Pat has reported 800+ failed clients, each lingering and consuming swap space. Sooner or later, the machine falls over with its swap full. To me, that's not keeping running regardless. > > - An option to cause a crash dump to be automatically generated to a > > <location> / ask / never generated (defaults to 'Ask'); > > The problem with that is it could rapidly fill up the disk and not be > solved. OK, to generate a crashdump to the *same* filename :-). > The 'never generate' option really isn't an > option... if it's crashing, It needs fixing Uh... Tony, I hate to say this, but I feel that's rather controlling on your part. If I'm providing a piece of software, I want it to be flexible enough that my users can do what they need with it. This may include disabling the crashdump on CVSNT if, for example, they have already sent you a crashdump and you are in the process of debugging it and releasing one of your timely fixed versions. Using technology to try to solve a social problem is, in my humble opinion, a mistake. Even if the default configuration remains unchanged, I'd argue (OK, I'm arguing :-) ) that there should be alternatives for those users for whom the default isn't appropriate. > Sending emails has been tried - it's a lot harder than it > looks, because > corporate configurations are quite hard to deal with. A lot > of the time > there isn't an SMTP server within reach, and the only thing > you can get > to is an Exchange MAPI connection (sometimes even then only > by dropping firewalls). Indeed. In which case, that particular organisation can't use that particular notification mechanism - tough. Sorry, I wasn't sufficiently clear in my original message: I'm not suggesting that email replaces the existing dialog, merely that it's an alternative for those who run the server lights-out. > Without the dialog a way of notifying the user is needed that is > intrusive and annoying enough that they do something about it > (like send > me the crashdump, post on the mailing list or whatever). Hmm. I get worried by passive sentences like that. Who is it needed by? Turn that sentence round: 'Without the dialog, <x> needs a way of notifying the user that is intrusive and annoying enough that they do something about it (like send me the crashdump, post on the mailing list or whatever).' Who is <x>? What human or organisational stakeholder in CVSNT has that requirement? Assume that I agree with this - and I do, as a default option. In a lights-out environment, however, the dialog isn't at all obvious - indeed, there may be no way whatsoever of seeing it, as it is displayed on the system console, I don't even have a monitor plugged in, and I do all of my admin via Terminal Services. So <x> may need an alternative that *is* 'intrusive and annoying enough'. > After a crash > you can't rely on the client/server connection. Pretty much > all you can > rely on is the ability to write to the disk an put up a dialog on the > server. Thinking aloud here. Application event log? If the process can't get to that, its authentication is probably sufficiently screwy that it can't get to filestore either. > You never get core dumps from the Unix boxes, because > something in inetd (at least on linux) disables them... It's probably done the API equivalent of 'limit coredumpsize 0'. Your process should be able to re-enable them via one API call to do with resource limits - sorry, I'm not near enough to my Linux boxes to give you the requisite call, but it's the same as the shell 'unlimit coredumpsize'. > There are instructions in the dialog... Never having seen one (maybe I should plug a monitor into our CVSNT server console!), I didn't know that. Cool! > it seems to work well enough. I disagree, for the reasons outlined above. - Peter