• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

For almost two weeks it is more the rule than the exception that develop.twiki.org has no skin because the links to twikiplugins/PatternSkin are broken.

This has been the case since the periodic update was made so only directories with changes are updated.

Today both ~develop and ~twiki4 is not working and ~twiki4 even gives me permission denied.

Will this be fixed in a near future? And if not. Can we revert back to the good old update scripts that worked on the old develop server. Sure the skin was missing occationally for about 30 seconds but you could always wait one minute and then it worked again.


You are "suffering" because I increased the frequency of the cron job.

I can easily reduce it again.


I've been using it fairly steadily over the last couple of days, and it has never "broken".



And once again I reopen a bug report which you have discarded.

It is 13 May 2006 22:24 UTC and Bugs have no skin again. And both on twiki4 and develop.

And it is not just me that see the problem. From IRC.

[00:21] <Lavr> Is bugs working for any of you with Skin right now? 
[00:21] <Drusilla> I'm angry at myself for not having done a better investigation when my project was first being discussed.
[00:21] <Drusilla> Because I don't have time to rewrite it in something else.
[00:22] <Drusilla> (Specifically RoR)
[00:22] * wbniv has joined #twiki
[00:22] <Drusilla> And, no, the skin isn't working. As usual.
[00:23] <Lavr> CDot sort of says that there is nothing wrong and that is always works.
[00:23] <Drusilla> Yeah, well, CDot is seriously overworked and probably very stressed out.
[00:24] * wbniv has quit IRC (Read error: 104 (Connection reset by peer))
[00:24] <Drusilla> As is Sven.
[00:25] <HaraldJoerg> Lavr: For me Bugs is working as usual.
[00:25] <Drusilla> To be accurate, anything on ~develop will break when it's svn upping
[00:25] <HaraldJoerg> (without skin ;->)

You must obviously have been lucky when you have not seen the problem the past days. But when I say Bugs have not been working stable for two weeks now it is true. I do not make up stories.

-- KJL

Bugs was bad for about 1-2 hours. It seems it became normal again when 10197/10198 was checked in. I will continue to report observations here.

-- KJL

I'm sorry, I'm going to discard this again, unless you have a practical proposal for how the bugbase can be made more stable without compromising it's role as a test platform. It will always glitch out when there are checkins. That's because it runs off live code, so we get immediate feedback if something goes wrong with a checkin. There are two windows onto the database; ~develop and ~twiki; if one isn't working, try the other. If they are both broken, then have a bit of patience. But the db is only unstable on the next refresh after a checkin.


And I reopen.

The error that is always there is that the skin elements cannot be accessed. It is clearly the pseudo install that does not run correctly to re-create the the links to the PatternSkin directory in the twikiplugins. This is happening so often that is cannot have anything to do with the actual code that people checkin. The problem started when you changed the update cron to "only update the directories that have changed". Before this change we had maybe 30-60 seconds periods where bugs did not work. Now it is most often many hours.

It seems that what releases the error condition and maybe also what triggers it is svn checkins. Something is rotten in those scripts.

And discarding this report is not going to make the problem go away.

The Bugs web is part of TWiki's face to the public. When our users/admins want to report bugs they should not be met by garbage.

I have been looking at the cron and post-commit scripts. Don't we have a race condition if someone check in something while the cron is in progress. The pseudo uninstall and install takes quite a long time and of the cron runs quite often - I would believe the probability of this happening is quite large. It could also explain why it takes a new SVN checkin to loosen up the condition.


It is 15 May 2006 - 22:55. Last checkin was SVN 10207 (my own checkins). That was 14:27 GMT or 8 hours ago. Bugs worked a few minutes after my checkin.

I checked bugs again at 22:12 GMT and waited a while to see of it recovered by itself. The current state at 22:12 and 22:55 is that both twiki4 and develop are without skin. You cannot see a path to any Pattern skin items. There are warnings like

It is always the same symptom.

I then went to InstalledPlugins in develop.

SpreadSheetPlugin Plugins: could not fully register SpreadSheetPlugin, no plugin topic
CommentPlugin Plugins: could not fully register CommentPlugin, no plugin topic
EditTablePlugin Plugins: could not fully register EditTablePlugin, no plugin topic
InterwikiPlugin Plugins: could not fully register InterwikiPlugin, no plugin topic
PreferencesPlugin Plugins: could not fully register PreferencesPlugin, no plugin topic
SlideShowPlugin Plugins: could not fully register SlideShowPlugin, no plugin topic
SmiliesPlugin Plugins: could not fully register SmiliesPlugin, no plugin topic
TablePlugin Plugins: could not fully register TablePlugin, no plugin topic
TestFixturePlugin Plugins: could not fully register TestFixturePlugin, no plugin topic.
TWiki::Plugins::TestFixturePlugin could not be loaded. Errors were:
Can't locate TWiki/Plugins/TestFixturePlugin.pm in @INC (@INC contains: /home/develop/twikisvn/lib/CPAN/lib//arch/ /home/develop/twikisvn/lib/CPAN/lib//5.8.5/i386-linux-thread-multi/ /home/develop/twikisvn/lib/CPAN/lib//5.8.5/ /home/develop/twikisvn/lib/CPAN/lib// /home/develop/public_html/conf /home/develop/twikisvn/lib . /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 70) line 1.
BEGIN failed--compilation aborted at (eval 70) line 1.
WysiwygPlugin Plugins: could not fully register WysiwygPlugin, no plugin topic

In twiki4 I get the same errors except the TestFixturePlugin.

So it is clear that the pseudo-install has failed to complete the linking.

When you view a bug report in twiki4 I see this at the top /~twiki4/pub 10207

When I view the same in develop I see /~develop/pub and below I see "Failed to include URL http://develop.twiki.org/~develop/pub/latest_svn.txt"

http://develop.twiki.org/~develop/pub/latest_svn.txt does exist. It is a text file that says 10207. Does the server know that develop.twiki.org is localhost?

I will add more observations as I see them.


At approx 23:05-23:10 bugs was back to normal. So it took around an hour to recover.

At the same time there were two checkins from Harald. 10208 and 10209 became visible on the Bugs RSS feed. They are reported to have been checked in 19:33 and 19:37 GMT. But the develop server seems to have the clock set 3 hours and 20 minutes wrong. The actual time for the checkins can be calculated to 22:53 and 22:57 GMT. The 10208 email from SF came through. Only one. Many emails are missing from bugs. Not sure if this is caused by SF or Bugs. SF is known to have email problems. I also checked my own merlin.lavrsen.dk which updates from SVN every 30 minutes. It got Haralds two checkins at 23:00 GMT.

GMTIME: 2019-11-19 - 23:42 <- 3:20 behind actual GMT!

I doubt this is the root cause but it is important to note this when you want to debug so we draw the right conclusions. Sven you should correct the clock and turn on ntpd.

As I write this it is 15 May 2006 0:01 GMT and bugs is still normal.


All is working here at 6:00 - 6:25 GMT. Changed to normal to get is off the Release Blocker list. This has nothing to do with releasing anything.


OK, you badgered me into wasting an hour on this.


Summary Bugs is almost always not working properly.
ReportedBy TWiki:Main.KennethLavrsen
Codebase ~twiki4, ~develop
SVN Range Sat, 06 May 2006 build 10108
AppliesTo Engine
Component BugDatabase
Priority Normal
CurrentState Closed

Checkins 10212 10213 10214 10215
TargetRelease n/a
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2006-05-15 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback