[cvsnt] Stop cvsnt 'crash dump' dialog?

Tony Hoyle tmh at nodomain.org
Thu Oct 28 14:12:37 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.

Peter Crowther wrote:
> [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.

If there is that kind of problem, it needs to be fixed.  Perhaps by 
trying a different version.  The problem is there is now way of knowing 
the state of the repository after a crash - if you have 800 of them then 
that could easily be 800 partial commits.

At the very least attempting to isolate the cause on a sandboxed 
client/server setup is a good idea - if only to find a temporary workaround.

> 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.

A crash is a not a social problem!  Getting adequate feedback sometimes 
is, but I get enough usuallly to diagnose problems - largely because of 
the crash dialog.  Before I had that I'd have to rely on verbal 
descriptions of the problem in most cases, and it took a lot longer to 
fix things (I still get that occasionally, eg. with the rename problem 
which doesn't crash, so I have no way of repeating it or finding out 
what's wrong).

> 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.

On balance I prefer the HTTP PUT idea.. I've already put something like 
this in for 2.0.59.

> 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?

Usually, whoever is in charge of monitoring it.  In most cases problems 
as serious as a crash will be found very quickly after install - 
probably before the repository goes live.

> 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.

A fair amount of stuff already gets written there.  It probably needs a 
bit more, though.

> 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'.

I've tried that one (setrlimit) and it didn't work for some reason. 
It's something I'll probably need to revisit at some point.

>>it seems to work well enough.
> I disagree, for the reasons outlined above.

 From my point of view I get the dumps, and stuff gets fixed - plus over 
time the number of dumps has decreased (when I first enabled it I was 
getting several a day...) which means it's helping to improve stability.

Getting some automatic stats would help though, and I'm planning on that 
for the next version.


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