[cvsnt] Stop cvsnt 'crash dump' dialog?

Peter Crowther Peter.Crowther at melandra.com
Thu Oct 28 09:42:55 BST 2004

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

> 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

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook