You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Hendrik <ja...@bigfoot.com> on 2003/09/25 19:06:43 UTC
repos not accessible after log files removed (II)
In addition to the report below and after a day of trial'n'error,
predominantly with the test repos:
Stopping Apache, recovering the repos, starting Apache gives
access back for some time. Normal LAN traffic is unaffected.
However, recovering only works when the removed logfiles (--only-
unused) are restored from backup before.
svnadmin lstxns revealed a couple of pending transactions,
supposedly from failed commits, both in the production repos as in
the test repos not used for about two weeks. I removed these with
svnadmin rmtxns.
But the problem persists: after some time I cannot access the
repos anymore, nor the server per browser at all (http://servername
times out). Doing ping shows the machine is alive, turning off the
firewall makes no difference. Here's the output:
C:\>ping dim4300
Ping Dim4300 [192.168.0.3] mit 32 Bytes Daten:
Antwort von 192.168.0.3: Bytes=32 Zeit=100ms TTL=128
Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
Ping-Statistik for 192.168.0.3:
Packets: sent = 4, received = 4, lost = 0 (0% loss),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 100ms, Mittelwert = 25ms
C:\>svn ls http://dim4300/svn/repos/trunk/internet/Marine
svn: RA layer request failed
svn: PROPFIND request failed on '/svn/repos/trunk/internet/Marine'
svn: PROPFIND of '/svn/repos/trunk/internet/Marine': could not connect to server
(http://dim4300)
C:\>
Since this happens with both repos which are accessed thruogh
different Apache servers, one of about 130MB, the other 80MB it
looks unlikely that it is related to size or my recent commit of 4500
files which went to the production repos only. But it seems to be
related somehow to removing obsolete logfiles.
System W2K, SVN .27, Apache 2.0.47 (there was no SVN .28 for
Windows, when .29 came I was too busy to trouble myself with the
schema change, when through the work .30 was around the corner
already, but now I am reluctant to upgrade a system that
fundamentally stopped working).
BTW I am amazed that just checking for updates (with TSVN)
produces about 50 logfiles!
Jan hendrik
> Hi all out there!
>
> A strange coincidence:
>
> some hours after a huge commit I could not access the production repos
> anymore (via Apache) and I had to stop and start Apache (restart would
> not do). Before starting I did svnadmin recover. On the time of the
> repos request the user of the SVN server machine got a Windows message
> about lacking virtual memory.
>
> The next day this repeated. Looking deeper into it I found that
> Apache did not respond at all. That is, server/manual timed out, too.
>
> Still thinking this were an Apache issue of some sort I was much
> surprised to find that except for the virtual memory message I had the
> same problem on my own machine accessing a local test repos via my own
> local Apache server. I had not done so for about a fortnight, but
> Apache always run quietly in the background.
>
> However, Sep. 7 I had run
>
> svnadmin lsdblogs --only-unused | xargs rm
>
> on it. And the same command after the commit to the other
> machine with the production repos.
>
> Going further back to my first steps with SVN before setting up
> Apache I had this with the first repos and file:/// access, too. That
> was with SVN .25. Checking out per file:///repos is impossible now
> again, the command hangs and finally times out. Looks like the repos
> does like to have *all* its logs around, even those reported to be no
> longer in use.
>
> Moving log files back into the db folder from a backup did not help
> though.
>
> Running SVN .27, Apache 2.0.47, Win2K SP2.
>
> Thanks for any suggestions.
>
> Jan Hendrik
> ---------------------------------------
> Freedom quote:
>
> We've gone astray from first principles.
> We've lost sight of the rule
> that individual freedom and ingenuity
> are at the very core of everything
> that we've accomplished.
> Government's first duty is to protect the people,
> not run their lives.
> -- Ronald Reagan
>
> ---------------------------------------
> Mailed with Pegasus Mail 3.12c (32bit).
> Never heard of it?
> Easy to use, full featured - and freely available.
> And *no* automatic virus activation and spreading.
> Take a look at http://www.pmail.com
> Give it a try - and you'll never miss anything else.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For
> additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------
Freedom quote:
There is no worse tyranny than to force a man to pay for
what he does not want merely because you think it would be good for him.
-- Robert Heinlein
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: repos not accessible after log
Daniel Patterson wrote on 30 Sep 2003, 17:26, at least in part:
> On Tue, 2003-09-30 at 17:21, Jan Hendrik wrote:
> > It would be interesting though to hear of this belongs to the
> > typical things one has to "accept" when using basically Unix apps as
> > Berkeley, Apache, Subversion in their Windows ports. (It's a small
> > peer-to-peer LAN here, all W2K SP2.)
>
> Just a quick note to point out that we've been using Subversion on
> win32 with win32 clients, apache 2.0.46, Subversion 0.23 for many
> months. We're up to a 3gb export size with 3700 commits (the
> repository is much bigger, in the order of 6-8gb). We've had zero
> problems the entire time (no lost data, no database locks, no apache
> restarts, etc).
Thanks for the input, Daniel. We are much smaller here (about 80
MB, 4500 HTML files and c. 1000 other, mostly JPG). And less
than 100 commits so far, due to the short time of use, first in test
and and semi-production mode, then September was relatively
quiet in regard of committable web work. The Apache has run here
quietly in the background since about mid-July. So did TSVN.
Well, and the other problems ... I have no solution so far nor see a
reason. Closest reason seemed to be removing unused logfiles, but
most recently it happened with logfiles untouched at all. Another
idea was/is that RAM may have to be in 1:1 relation to repos size,
but in GB sizes this is illusional (we have 128-144MB here).
Jan Hendrik
---------------------------------------
Freedom quote:
I would rather be exposed to the inconveniences
attending too much liberty than to those attending
too small a degree of it.
-- Thomas Jefferson to Archibald Stuart, 1791
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Philip Martin <ph...@codematters.co.uk>.
"Jan Hendrik" <ja...@bigfoot.com> writes:
> To complete this barely noticed thread at least for my own records:
I guess you got so little response because nobody knows what to suggest.
> After another recover I could dump the corrupt repos without trouble
> and load it into a virginal .30 repos. Doing a verify on the repos also
> showed no troubles. However, after a few commits and updates it
> was business as usual: no longer accessable. I had not even
> removed the unused logfiles at that point, something I supposed to
> be the cause so far.
Your initial claim, that removing the log files made the repository
inaccessible, sounded extremely unlikely. As far as I can see you
have now discounted that, and you are left with a simple "Subversion
doesn't work on my Windows platform".
> It would be interesting though to hear of this belongs to the typical
> things one has to "accept" when using basically Unix apps as
> Berkeley, Apache, Subversion in their Windows ports. (It's a small
> peer-to-peer LAN here, all W2K SP2.)
As far as I know other people are using Subversion and Apache on
Windows, but I don't do it myself so I can't really help. If you
describe your system and setup more fully it is possible someone will
recognise what you are doing wrong.
>> > C:\>svn ls http://dim4300/svn/repos/trunk/internet/Marine
>> > svn: RA layer request failed
>> > svn: PROPFIND request failed on '/svn/repos/trunk/internet/Marine'
>> > svn: PROPFIND of '/svn/repos/trunk/internet/Marine': could not
>> > connect to server
>> > (http://dim4300)
That simply shows that the client cannot communicate with the server,
you will get the same error if Apache is not running. To get more
information you will need to debug the server (or possibly the client
over ra_local).
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Tue, 2003-09-30 at 17:21, Jan Hendrik wrote:
> It would be interesting though to hear of this belongs to the typical
> things one has to "accept" when using basically Unix apps as
> Berkeley, Apache, Subversion in their Windows ports. (It's a small
> peer-to-peer LAN here, all W2K SP2.)
Just a quick note to point out that we've been using Subversion
on win32 with win32 clients, apache 2.0.46, Subversion 0.23
for many months. We're up to a 3gb export size with 3700 commits
(the repository is much bigger, in the order of 6-8gb).
We've had zero problems the entire time (no lost data, no
database locks, no apache restarts, etc).
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: repos not accessible after log
mark benedetto king wrote on 6 Oct 2003, 10:34, at least in part:
> On Mon, Oct 06, 2003 at 01:33:52PM +0200, Jan Hendrik wrote:
> >
> > Should 16MB less RAM make such a difference? With 128MB the
> > repos is corrupted virtually immediately just when accessed over the
> > LAN, even if just booted and running no other apps, while 144MB
> > running since days with several big apps is corrupted after several
> > commits of 100-300 files only? It sounds possible, but not very
> > convincing. All the more as the new repos still seems to healthy.
>
> How much swap do you have configured for each machine?
1 GB on the P4 128 MB RAM box.
460 MB on the old 144MB RAM machine (tried more once, but
slowed down overall operation).
Jan Hendrik
---------------------------------------
Freedom quote:
Our policy is simple:
We are not going to betray our friends,
reward the enemies of freedom,
or permit fear and retreat to become American policies. ...
None of the four wars in my lifetime
came about because we were too strong.
It is weakness ... that invites adventurous adversaries
to make mistaken judgments.
-- Ronald Reagan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by mark benedetto king <mb...@lowlatency.com>.
On Mon, Oct 06, 2003 at 01:33:52PM +0200, Jan Hendrik wrote:
>
> Should 16MB less RAM make such a difference? With 128MB the
> repos is corrupted virtually immediately just when accessed over
> the LAN, even if just booted and running no other apps, while
> 144MB running since days with several big apps is corrupted after
> several commits of 100-300 files only? It sounds possible, but not
> very convincing. All the more as the new repos still seems to
> healthy.
How much swap do you have configured for each machine?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: repos not accessible after log
Michael Wood wrote on 2 Oct 2003, 14:42, at least in part:
[text is snipped]
> > > My advice is to convert the drive holding the repository files to
> > > NTFS and see if the system remains stable.
> >
> If this does solve the problem please let us know so the FAQ can be
> updated.
Gladly I'll do! So far it is just a report of the state though, not a
problem solved. Luckily I found that side by side with the WinME
partition there was unused disk space so it was easy to resize this
into one and make it NTFS. (WinME is not so much a loss,
especially as silly Dell/Phoenix BIOS does not allow for secure
multiboot anyway.)
However, NTFS does not make a difference: it was the same game
again, loading the dump of the recovered repos into a new repos,
accessing it locally per file:// and http:// (both with SVN client and
browser) works repeatedly, but then doing essentially the same
things (update, commit, browse) via http:// from the other machine
wrecks it again practically immediately. Updates + commits
concerned few files only, usually less than 50, at most less than
100.
OTOH the repos I created from restored working copies currently
*seems* to be working both locally and remotely. However, just
after creating it last week or so I had the same problems at first,
too. It is recovered twice or thrice, too. It always sat side by side
with the other.
This should eliminate FAT32/NTFS. There might be, however,
evidence that it RAM may be an issue:
Beside I loaded the corrupting repos dump into a new one on my
own machine and checked out two working copies, one with file://,
the other with http://. During two days I got no problems and
yesterday I checked out another copy, this time on the other
machine and tried several small updates, commits and browsing as
above *without* the repos being corrupted. Today I did several
larger updates/commits (5 to 300 files each) and after the 7th or
8th it got corrupted, too.
Mine is the old P200 144 MB machine with FAT32 only and a
currently badly fragmented disk. And while the "corrupting" P4
128MB box was just booted and only file manager, browser (IE) a/o
command line/TSVN loaded, mine runs since several days,
additionally to the above I have Word97, Homesite5, Pegasus Mail
and Opera running. Especially Word and Homesite do some
swapping.
Should 16MB less RAM make such a difference? With 128MB the
repos is corrupted virtually immediately just when accessed over
the LAN, even if just booted and running no other apps, while
144MB running since days with several big apps is corrupted after
several commits of 100-300 files only? It sounds possible, but not
very convincing. All the more as the new repos still seems to
healthy.
I put RAM upgrade onto the purchase list though there is not much
to do. Contradictionary references say the Dell Dimension 4300 P4
can take 1GB - or just another 128MB at all. The other machine is
full with 144MB anyway.
I compared the Apache conf file of both machines and they differ in
only those things they naturally have to differ: driveletters, server
name/IP, admin email.
The SVN conf differs most remarkably in the opening single
quotes: straigth one in mine, French ones in the other. And the
latter was *not* updated to .30!
Maybe one strange thing that could or could not give another clue:
No matter what repos I browse from where - on my machine MS IE
5.01, Netscape 4.73, and Opera 6.05 display HTML files normal,
that is just like you would see them on the web. On the other
machine only MS IE 5.5 does it, both Opera and Netscape (same
versions) show the HTML code.
Dunno if this has brought us any further. From postings I
understand that here and there unexplained and persistent repos
corruptions have happened to some before. Generally I'd be glad if
that new repos continues to work, but not knowing what happens
and what makes the difference here between local http and remote
http is at least not satisfiying. But if there is no other option I have
to wait till I get 256 MB into that box (no, we are in the country side
and even in the nearest town you never know if there is a computer
shop or if the last has already gone without the next trying again
<g>).
Jan Hendrik
---------------------------------------
Freedom quote:
Many of our fellow citizens no longer have the tolerant souls
and morals of free men and women.
They have the souls and morals of busybodies
and petty tyrants who want to run their neighbors' lives.
-- Edward L. Hudgins
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Thu, Oct 02, 2003 at 12:47:25PM +0200, Jan Hendrik wrote:
> Concerning Re: repos not accessible after log
> John Peacock wrote on 1 Oct 2003, 9:55, at least in part:
>
[snip]
> > My advice is to convert the drive holding the repository files to
> > NTFS and see if the system remains stable.
>
> I will follow your appreciated advice, but must see how to do this
> without breaking the system else. It will take some time though.
[snip]
If this does solve the problem please let us know so the FAQ can be
updated.
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: repos not accessible after log
John Peacock wrote on 1 Oct 2003, 9:55, at least in part:
> Jan Hendrik wrote:
> > The server is a P4 1.6GB box, 128 MB RAM, 10/100 LAN, W2K
> > Pro SP2, FAT32, no AV, no firewall, Apache 2.0.47 as service (no
> > problems since setup about 6-7 weeks ago). SVN was .27 for about the
> > same time, problem began about a week ago and persisted after
> > dump/load to a new .30 repos.
> >
> > My machine is a P200, 144 MB RAM, 10 Mbit LAN, W2K Pro
> > SP2, FAT32, no AV, Kerio Firewall 2.1.5 with SVN/TSVN allowed
> > on any ports with local network mask, Apache running with no
> > problems since mid/end July. SVN started with .25, updated to .27,
> > now updated together with the above machine to .30.
>
> FAT32 seems to be the common element. Is there some reason you cannot
> use NTFS on at least the server? FAT32 is not really not suitable for
> server processes; it is fragile and lacking most features of modern
> (and not so modern) multiuser file systems.
Hmm, there are pros and cons. I like to have a DOS boot disk with
F-Prot and being able to access my HDD. It was never necessary
so far, but ... That's perhaps the most important reason that I still
have FAT32. And both machines still have Win9x on one partition
though I have not booted to it since more than a year. However, the
Win9x partitions are not large enough to make them the home of
the repos while splitting up the data partition would break the whole
setup (driveletters). Finally Ghost does not compress NTFS
partitions making disk clones very huge, though this concerns
more the system and application partitions as i do not make disk
clones of data.
I must see how to solve this, it's nothing to decide (or change) in
an afternoon. At least it looks like complete repartioning and much
work with clones and backups ...
> However, see the second paragraph of item 2 here:
>
> http://www.sleepycat.com/docs/ref/build_win/notes.html
I read this and the whole page. Most is beyond my technical
scope, but I see the point about recovery and corruption at the end
of the paragraph. My general - non-technical - impression is that
Berkeley and Windows are more like cat - even sleepy! - and dog,
not an ideal pair. ;-)
> My advice is to convert the drive holding the repository files to NTFS
> and see if the system remains stable.
I will follow your appreciated advice, but must see how to do this
without breaking the system else. It will take some time though.
Jan Hendrik
---------------------------------------
Freedom quote:
As a man is said to have a right to his property,
he may be equally said to have a property in his rights.
Where an excess of power prevails,
property of no sort is duly respected.
No man is safe in his opinions, his person, his faculties,
or his possessions.
-- James Madison, National Gazzette, 1792
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by John Peacock <jp...@rowman.com>.
Jan Hendrik wrote:
> The server is a P4 1.6GB box, 128 MB RAM, 10/100 LAN, W2K
Oh, one other thing. RAM is cheap; buy lots of it! You are almost certainly
using swapspace for almost all but the most trivial operations. Although it's
been a while since Subversion had serious problems with resource starvation, the
software is still much happier with lots of RAM available.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by John Peacock <jp...@rowman.com>.
Jan Hendrik wrote:
> The server is a P4 1.6GB box, 128 MB RAM, 10/100 LAN, W2K
> Pro SP2, FAT32, no AV, no firewall, Apache 2.0.47 as service (no
> problems since setup about 6-7 weeks ago). SVN was .27 for
> about the same time, problem began about a week ago and
> persisted after dump/load to a new .30 repos.
>
> My machine is a P200, 144 MB RAM, 10 Mbit LAN, W2K Pro
> SP2, FAT32, no AV, Kerio Firewall 2.1.5 with SVN/TSVN allowed
> on any ports with local network mask, Apache running with no
> problems since mid/end July. SVN started with .25, updated to .27,
> now updated together with the above machine to .30.
FAT32 seems to be the common element. Is there some reason you cannot use NTFS
on at least the server? FAT32 is not really not suitable for server processes;
it is fragile and lacking most features of modern (and not so modern) multiuser
file systems.
However, see the second paragraph of item 2 here:
http://www.sleepycat.com/docs/ref/build_win/notes.html
which certainly sounds like what you are experiencing. Someone more familiar
with how Subversion and BerkeleyDB interact will have to weigh in as to whether
this could be the problem.
My advice is to convert the drive holding the repository files to NTFS and see
if the system remains stable.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
Thanks for the all replies and sorry for the delay on my side, but I
was out yesterday. This will become rather long though and
perhaps a debug would be more informative if only someone could
instruct me what to do - I have only very vague ideas about
debugging. And if it needs to make and build and compile a special
version first I would be lost anyway ...
Concerning Re: repos not accessible after log
John Peacock wrote on 30 Sep 2003, 10:19, at least in part:
> Michael Wood wrote:
>
> > He's saying that http:// between two machines causes the problem
> > more frequently than http://localhost/ or file://, but the problems
> > still occur with http://localhost/ and file://.
Thanks for straightening out what I tried to say, Michael! That's
exactly how it seems to be. Usual scenario is I recover the repos
sitting at the server machine, start Apache again and access the
repos with CL client, TSVN and browser (MS IE 5.5 & Opera)
several times with both file:// and http://. Mostly things are fine.
Then I go up to my machine and start doing the same things with
http:// only and it does not take long and the repos is corrupted
again. But as said, sometimes it already starts again while still
being at the server machine.
> If that is what he is saying (and I agree that seems plausible), it
> makes no sense. Apache treats localhost connections identically to
> network connections (except for purposes of authorization). It all
> goes through the same IP stack.
I would expect that, too.
> Is this FAQ applicable?
>
> http://subversion.tigris.org/project_faq.html#windows-xp-server
No, don't have XP. And no, I do not access the repos through file://
on the network drive (though mapped on my machine as J:\). No
machine runs a virus scanner in the background. I'll try to describe
the environment more precisely:
The server is a P4 1.6GB box, 128 MB RAM, 10/100 LAN, W2K
Pro SP2, FAT32, no AV, no firewall, Apache 2.0.47 as service (no
problems since setup about 6-7 weeks ago). SVN was .27 for
about the same time, problem began about a week ago and
persisted after dump/load to a new .30 repos.
My machine is a P200, 144 MB RAM, 10 Mbit LAN, W2K Pro
SP2, FAT32, no AV, Kerio Firewall 2.1.5 with SVN/TSVN allowed
on any ports with local network mask, Apache running with no
problems since mid/end July. SVN started with .25, updated to .27,
now updated together with the above machine to .30.
The repos that started the trouble was originally created on my
machine as a test repos and filled with live data from our website
projects. At first accessed with file:// + svn:// (few time only), later
with http://, too. When I had become familiar with basic SVN the
repos developed into a semi-production repos, that is I kept a few
private copies of other's website projects and committed/updated
them to the repos by both file:// and http://, just as if it had gone
live already. In a second step I copied the repos to the first
machine which shall become the server and relocated my "private"
working copies accordingly. As things still went well I finally moved
the original website projects out of way and checked out working
copies from the repos to start production. For about 10 days this
worked as well, though there were only few commits due to current
work cycle here. At any time it was on the same machine as
Apache. The partition of the repos has ample space (6-8 GB).
I had, however, kept a copy of the repos on my machine for later
tests and further learning. Only test since was removing unused
logfiles.
Trouble began shortly after removing logfiles of the production
repos. I then tried the kept test repos and run into the same things.
Removing logfiles seemed to be the connecting line and at first
things looked like to become stable again when restoring logfiles
from ZIP file before doing a recover. For the update to .30 I did the
dump with logfiles restored.
Obviously when the repos becomes inaccessible on an update or
commit command a pending transaction is left over. I found a few
and removed them, but no cure.
No other soft/hardware installed but the SVN/TSVN updates.
Does this give any clue? Can I give more specific, technical
information? I really like SVN for ease of use, but at some point
something must have gone wrong here and is staying wrong ...
TIA - Jan Hendrik
---------------------------------------
Freedom quote:
The government's view of the economy
can be summed up in a few short phrases:
If it moves, tax it. If it keeps moving, regulate it.
And if it stops moving, subsidize it.
-- Ronald Reagan
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by John Peacock <jp...@rowman.com>.
Michael Wood wrote:
> He's saying that http:// between two machines causes the problem more
> frequently than http://localhost/ or file://, but the problems still
> occur with http://localhost/ and file://.
>
If that is what he is saying (and I agree that seems plausible), it makes no
sense. Apache treats localhost connections identically to network connections
(except for purposes of authorization). It all goes through the same IP stack.
Is this FAQ applicable?
http://subversion.tigris.org/project_faq.html#windows-xp-server
That wouldn't explain why file:// would have problems, though...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Tue, Sep 30, 2003 at 09:36:03AM -0400, John Peacock wrote:
> Jan Hendrik wrote:
> >Generally it looks like it happens faster or at least more likely
> >when the repos is accessed via Apache through the LAN than via Apache
> >a/o file:/// on the local disk. But I stress the "faster" and "more
> >likely".
>
> I don't quite understand that paragraph; are you saying that access
> through http:// is more likely to cause the problem than file://
> access?
He's saying that http:// between two machines causes the problem more
frequently than http://localhost/ or file://, but the problems still
occur with http://localhost/ and file://.
> [...] Are you
> attempting to use file:// access to a network mounted share? Is the
> repository local to the Apache server or is it located on a mounted
> share?
If so, don't do that :)
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by John Peacock <jp...@rowman.com>.
Jan Hendrik wrote:
> Generally it looks like it happens faster or at least more likely when
> the repos is accessed via Apache through the LAN than via
> Apache a/o file:/// on the local disk. But I stress the "faster" and
> "more likely".
>
I don't quite understand that paragraph; are you saying that access through
http:// is more likely to cause the problem than file:// access?
> Since for me there is no pattern I can follow after about three
> working days spent on this I recalled Subversion from production to
> low level testing. That is I keep two or three private copies of
> working copies and update/commit them occasionally while doing
> production by old-fashioned synchronizing again. And give Perforce
> a second try.
>
As already pointed out, no one responded most likely because no one has had
these problems. There is likely to be something specific to your environment
that is causing problems to surface.
Are you running any sort of virus-scanner on the server? Do you have the
repository located on a FAT32 volume or an NTFS volume? Are you attempting to
use file:// access to a network mounted share? Is the repository local to the
Apache server or is it located on a mounted share?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
To complete this barely noticed thread at least for my own records:
After another recover I could dump the corrupt repos without trouble
and load it into a virginal .30 repos. Doing a verify on the repos also
showed no troubles. However, after a few commits and updates it
was business as usual: no longer accessable. I had not even
removed the unused logfiles at that point, something I supposed to
be the cause so far.
Generally it looks like it happens faster or at least more likely when
the repos is accessed via Apache through the LAN than via
Apache a/o file:/// on the local disk. But I stress the "faster" and
"more likely".
Since for me there is no pattern I can follow after about three
working days spent on this I recalled Subversion from production to
low level testing. That is I keep two or three private copies of
working copies and update/commit them occasionally while doing
production by old-fashioned synchronizing again. And give Perforce
a second try.
Though in painful work I could reconstruct data of about 100
changed files, in terms of source control - as I understand it - I have
lost data. And in view of recent major changes on the website files
the loss is really huge for I lost the ability to undo these, no matter
if I need to revert or not.
It would be interesting though to hear of this belongs to the typical
things one has to "accept" when using basically Unix apps as
Berkeley, Apache, Subversion in their Windows ports. (It's a small
peer-to-peer LAN here, all W2K SP2.)
Jan Hendrik
Concerning Re: repos not accessible after log
Jan Hendrik wrote on 27 Sep 2003, 11:29, at least in part:
> As it continued to be an on and off with the repos - that is, do a
> recover and remove unused logfiles, accessing it a few times
> successfully and then no access again and start with recover again - I
> created a new repos and will now upgrade to SVN .30 and see what
> happens then after removing unused logfiles.
>
> Since I could not have any trust in that constantly broken/recovered
> repos anymore I regard its contents as being lost and reconstructed
> data by manually synchronizing the existing working copies (comparing
> and merging about 100 files in WinMerge - fortunately not all 4500
> files!) instead of using a dump.
>
> Hope this will not happen again! It was not very amusing nor do I like
> gigabytes filled with logfiles, especially when just a Check for
> updates per TSVN crates about 50 new ones!
>
> Jan Hendrik
>
> Concerning repos not accessible after log file
> Jan Hendrik wrote on 25 Sep 2003, 21:06, at least in part:
>
> > In addition to the report below and after a day of trial'n'error,
> > predominantly with the test repos:
> >
> > Stopping Apache, recovering the repos, starting Apache gives
> > access back for some time. Normal LAN traffic is unaffected.
> > However, recovering only works when the removed logfiles (--only-
> > unused) are restored from backup before.
> >
> > svnadmin lstxns revealed a couple of pending transactions,
> > supposedly from failed commits, both in the production repos as in
> > the test repos not used for about two weeks. I removed these with
> > svnadmin rmtxns.
> >
> > But the problem persists: after some time I cannot access the
> > repos anymore, nor the server per browser at all (http://servername
> > times out). Doing ping shows the machine is alive, turning off the
> > firewall makes no difference. Here's the output:
> >
> > C:\>ping dim4300
> >
> > Ping Dim4300 [192.168.0.3] mit 32 Bytes Daten:
> >
> > Antwort von 192.168.0.3: Bytes=32 Zeit=100ms TTL=128
> > Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
> > Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
> > Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
> >
> > Ping-Statistik for 192.168.0.3:
> > Packets: sent = 4, received = 4, lost = 0 (0% loss),
> > Ca. Zeitangaben in Millisek.:
> > Minimum = 0ms, Maximum = 100ms, Mittelwert = 25ms
> >
> > C:\>svn ls http://dim4300/svn/repos/trunk/internet/Marine
> > svn: RA layer request failed
> > svn: PROPFIND request failed on '/svn/repos/trunk/internet/Marine'
> > svn: PROPFIND of '/svn/repos/trunk/internet/Marine': could not
> > connect to server
> > (http://dim4300)
> >
> > C:\>
> >
> > Since this happens with both repos which are accessed thruogh
> > different Apache servers, one of about 130MB, the other 80MB it
> > looks unlikely that it is related to size or my recent commit of
> > 4500 files which went to the production repos only. But it seems to
> > be related somehow to removing obsolete logfiles.
> >
> > System W2K, SVN .27, Apache 2.0.47 (there was no SVN .28 for
> > Windows, when .29 came I was too busy to trouble myself with the
> > schema change, when through the work .30 was around the corner
> > already, but now I am reluctant to upgrade a system that
> > fundamentally stopped working).
> >
> > BTW I am amazed that just checking for updates (with TSVN)
> > produces about 50 logfiles!
> >
> > Jan hendrik
> > > Hi all out there!
> > >
> > > A strange coincidence:
> > >
> > > some hours after a huge commit I could not access the production
> > > repos anymore (via Apache) and I had to stop and start Apache
> > > (restart would not do). Before starting I did svnadmin recover. On
> > > the time of the repos request the user of the SVN server machine
> > > got a Windows message about lacking virtual memory.
> > >
> > > The next day this repeated. Looking deeper into it I found that
> > > Apache did not respond at all. That is, server/manual timed out,
> > > too.
> > >
> > > Still thinking this were an Apache issue of some sort I was much
> > > surprised to find that except for the virtual memory message I had
> > > the same problem on my own machine accessing a local test repos
> > > via my own local Apache server. I had not done so for about a
> > > fortnight, but Apache always run quietly in the background.
> > >
> > > However, Sep. 7 I had run
> > >
> > > svnadmin lsdblogs --only-unused | xargs rm
> > >
> > > on it. And the same command after the commit to the other
> > > machine with the production repos.
> > >
> > > Going further back to my first steps with SVN before setting up
> > > Apache I had this with the first repos and file:/// access, too.
> > > That was with SVN .25. Checking out per file:///repos is
> > > impossible now again, the command hangs and finally times out.
> > > Looks like the repos does like to have *all* its logs around, even
> > > those reported to be no longer in use.
> > >
> > > Moving log files back into the db folder from a backup did not
> > > help though.
> > >
> > > Running SVN .27, Apache 2.0.47, Win2K SP2.
> > >
> > > Thanks for any suggestions.
> > >
> > > Jan Hendrik
> > > ---------------------------------------
> > > Freedom quote:
> > >
> > > We've gone astray from first principles.
> > > We've lost sight of the rule
> > > that individual freedom and ingenuity
> > > are at the very core of everything
> > > that we've accomplished.
> > > Government's first duty is to protect the people,
> > > not run their lives.
> > > -- Ronald Reagan
> > >
> > > ---------------------------------------
> > > Mailed with Pegasus Mail 3.12c (32bit).
> > > Never heard of it?
> > > Easy to use, full featured - and freely available.
> > > And *no* automatic virus activation and spreading.
> > > Take a look at http://www.pmail.com
> > > Give it a try - and you'll never miss anything else.
> > >
> > > ------------------------------------------------------------------
> > > -- - To unsubscribe, e-mail:
> > > users-unsubscribe@subversion.tigris.org For additional commands,
> > > e-mail: users-help@subversion.tigris.org
> > >
> >
> >
> > ---------------------------------------
> > Freedom quote:
> >
> > There is no worse tyranny than to force a man to pay for
> > what he does not want merely because you think it would be good
> > for him.
> > -- Robert Heinlein
> >
> > ---------------------------------------
> > Mailed with Pegasus Mail 3.12c (32bit).
> > Never heard of it?
> > Easy to use, full featured - and freely available.
> > And *no* automatic virus activation and spreading.
> > Take a look at http://www.pmail.com
> > Give it a try - and you'll never miss anything else.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
>
> ---------------------------------------
> Freedom quote:
>
> We've gone astray from first principles.
> We've lost sight of the rule
> that individual freedom and ingenuity
> are at the very core of everything
> that we've accomplished.
> Government's first duty is to protect the people,
> not run their lives.
> -- Ronald Reagan
>
> ---------------------------------------
> Mailed with Pegasus Mail 3.12c (32bit).
> Never heard of it?
> Easy to use, full featured - and freely available.
> And *no* automatic virus activation and spreading.
> Take a look at http://www.pmail.com
> Give it a try - and you'll never miss anything else.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For
> additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------
Freedom quote:
We believed then and now:
There are no limits to growth and human progress
when men and women are free to follow their dreams.
And we were right to believe that.
-- Ronald Reagan
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: repos not accessible after log
mark benedetto king wrote on 25 Sep 2003, 16:13, at least in part:
> On Thu, Sep 25, 2003 at 09:06:43PM +0200, Jan Hendrik wrote:
> >
> > System W2K, SVN .27, Apache 2.0.47 (there was no SVN .28 for
> > Windows, when .29 came I was too busy to trouble myself with the
> > schema change, when through the work .30 was around the corner
> > already, but now I am reluctant to upgrade a system that
> > fundamentally stopped working).
> >
>
> Revision 6837, about a week after the 0.27 release, IIRC, fixed
> a potential problem where "svnadmin recover" could actually corrupt a
> repository. It is possible that you ran into this.
Except that the trouble arised *before* doing a recover, but *after*
removing unused logfiles. This after goes for both the repos which
are on different machines using their own Apaches.
> I recall that you mentioned that you had stopped Apache before running
> a recovery. Do you happen to remember noticing "hung" httpd processes
> later; in other words, is it possible that "apachectl stop" did not
> actually kill all of the httpd processes?
No, as far as I understand this there was nothing running or hung.
In the browser I had closed windows attempting to connect to the
repos, requests per TSVN closed, commands on command line
CTRL-C'd. So to my understanding there was no latent process
when stopping Apache.
Just tested things with file:///, too, and there access is lost as well.
This should be final evidence that Apache is not the cause for this.
The strange thing is that after running recover things work for some
short time before the trouble starts again.
Jan Hendrk
---------------------------------------
Freedom quote:
We believed then and now:
There are no limits to growth and human progress
when men and women are free to follow their dreams.
And we were right to believe that.
-- Ronald Reagan
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by mark benedetto king <mb...@lowlatency.com>.
On Thu, Sep 25, 2003 at 09:06:43PM +0200, Jan Hendrik wrote:
>
> System W2K, SVN .27, Apache 2.0.47 (there was no SVN .28 for
> Windows, when .29 came I was too busy to trouble myself with the
> schema change, when through the work .30 was around the corner
> already, but now I am reluctant to upgrade a system that
> fundamentally stopped working).
>
Revision 6837, about a week after the 0.27 release, IIRC, fixed
a potential problem where "svnadmin recover" could actually corrupt
a repository. It is possible that you ran into this.
I recall that you mentioned that you had stopped Apache before running
a recovery. Do you happen to remember noticing "hung" httpd processes
later; in other words, is it possible that "apachectl stop" did not
actually kill all of the httpd processes?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: repos not accessible after log files removed (II)
Posted by Jan Hendrik <ja...@bigfoot.com>.
As it continued to be an on and off with the repos - that is, do a
recover and remove unused logfiles, accessing it a few times
successfully and then no access again and start with recover again
- I created a new repos and will now upgrade to SVN .30 and see
what happens then after removing unused logfiles.
Since I could not have any trust in that constantly broken/recovered
repos anymore I regard its contents as being lost and
reconstructed data by manually synchronizing the existing working
copies (comparing and merging about 100 files in WinMerge -
fortunately not all 4500 files!) instead of using a dump.
Hope this will not happen again! It was not very amusing nor do I
like gigabytes filled with logfiles, especially when just a Check for
updates per TSVN crates about 50 new ones!
Jan Hendrik
Concerning repos not accessible after log file
Jan Hendrik wrote on 25 Sep 2003, 21:06, at least in part:
> In addition to the report below and after a day of trial'n'error,
> predominantly with the test repos:
>
> Stopping Apache, recovering the repos, starting Apache gives
> access back for some time. Normal LAN traffic is unaffected.
> However, recovering only works when the removed logfiles (--only-
> unused) are restored from backup before.
>
> svnadmin lstxns revealed a couple of pending transactions,
> supposedly from failed commits, both in the production repos as in the
> test repos not used for about two weeks. I removed these with svnadmin
> rmtxns.
>
> But the problem persists: after some time I cannot access the
> repos anymore, nor the server per browser at all (http://servername
> times out). Doing ping shows the machine is alive, turning off the
> firewall makes no difference. Here's the output:
>
> C:\>ping dim4300
>
> Ping Dim4300 [192.168.0.3] mit 32 Bytes Daten:
>
> Antwort von 192.168.0.3: Bytes=32 Zeit=100ms TTL=128
> Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
> Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
> Antwort von 192.168.0.3: Bytes=32 Zeit<10ms TTL=128
>
> Ping-Statistik for 192.168.0.3:
> Packets: sent = 4, received = 4, lost = 0 (0% loss),
> Ca. Zeitangaben in Millisek.:
> Minimum = 0ms, Maximum = 100ms, Mittelwert = 25ms
>
> C:\>svn ls http://dim4300/svn/repos/trunk/internet/Marine
> svn: RA layer request failed
> svn: PROPFIND request failed on '/svn/repos/trunk/internet/Marine'
> svn: PROPFIND of '/svn/repos/trunk/internet/Marine': could not connect
> to server
> (http://dim4300)
>
> C:\>
>
> Since this happens with both repos which are accessed thruogh
> different Apache servers, one of about 130MB, the other 80MB it
> looks unlikely that it is related to size or my recent commit of 4500
> files which went to the production repos only. But it seems to be
> related somehow to removing obsolete logfiles.
>
> System W2K, SVN .27, Apache 2.0.47 (there was no SVN .28 for
> Windows, when .29 came I was too busy to trouble myself with the
> schema change, when through the work .30 was around the corner
> already, but now I am reluctant to upgrade a system that fundamentally
> stopped working).
>
> BTW I am amazed that just checking for updates (with TSVN)
> produces about 50 logfiles!
>
> Jan hendrik
> > Hi all out there!
> >
> > A strange coincidence:
> >
> > some hours after a huge commit I could not access the production
> > repos anymore (via Apache) and I had to stop and start Apache
> > (restart would not do). Before starting I did svnadmin recover. On
> > the time of the repos request the user of the SVN server machine got
> > a Windows message about lacking virtual memory.
> >
> > The next day this repeated. Looking deeper into it I found that
> > Apache did not respond at all. That is, server/manual timed out,
> > too.
> >
> > Still thinking this were an Apache issue of some sort I was much
> > surprised to find that except for the virtual memory message I had
> > the same problem on my own machine accessing a local test repos via
> > my own local Apache server. I had not done so for about a fortnight,
> > but Apache always run quietly in the background.
> >
> > However, Sep. 7 I had run
> >
> > svnadmin lsdblogs --only-unused | xargs rm
> >
> > on it. And the same command after the commit to the other
> > machine with the production repos.
> >
> > Going further back to my first steps with SVN before setting up
> > Apache I had this with the first repos and file:/// access, too.
> > That was with SVN .25. Checking out per file:///repos is impossible
> > now again, the command hangs and finally times out. Looks like the
> > repos does like to have *all* its logs around, even those reported
> > to be no longer in use.
> >
> > Moving log files back into the db folder from a backup did not help
> > though.
> >
> > Running SVN .27, Apache 2.0.47, Win2K SP2.
> >
> > Thanks for any suggestions.
> >
> > Jan Hendrik
> > ---------------------------------------
> > Freedom quote:
> >
> > We've gone astray from first principles.
> > We've lost sight of the rule
> > that individual freedom and ingenuity
> > are at the very core of everything
> > that we've accomplished.
> > Government's first duty is to protect the people,
> > not run their lives.
> > -- Ronald Reagan
> >
> > ---------------------------------------
> > Mailed with Pegasus Mail 3.12c (32bit).
> > Never heard of it?
> > Easy to use, full featured - and freely available.
> > And *no* automatic virus activation and spreading.
> > Take a look at http://www.pmail.com
> > Give it a try - and you'll never miss anything else.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
>
> ---------------------------------------
> Freedom quote:
>
> There is no worse tyranny than to force a man to pay for
> what he does not want merely because you think it would be good
> for him.
> -- Robert Heinlein
>
> ---------------------------------------
> Mailed with Pegasus Mail 3.12c (32bit).
> Never heard of it?
> Easy to use, full featured - and freely available.
> And *no* automatic virus activation and spreading.
> Take a look at http://www.pmail.com
> Give it a try - and you'll never miss anything else.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For
> additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------
Freedom quote:
We've gone astray from first principles.
We've lost sight of the rule
that individual freedom and ingenuity
are at the very core of everything
that we've accomplished.
Government's first duty is to protect the people,
not run their lives.
-- Ronald Reagan
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org