On Sun, Mar 26, 2017 at 12:49:04PM +0100, Dave Symes wrote:
> Last night the spring clock time changes happened.
>
> RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
>
> As per usual, for as long as I can remember, ALL my RPCEmu installs that
> use Organizer were Organizer wise FU.
> Organizer failed to run because of some file time stamp failure with its
> files.
Can you describe the exact eror or behaviour you see when running this?
> Wrong! I've discussed this with Martin over the years...
Can you get Marin Avison to describe the issue as he sees it?
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 26 March 2017
[Rpcemu] RPCEmu and Time
Last night the spring clock time changes happened.
RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
As per usual, for as long as I can remember, ALL my RPCEmu installs that
use Organizer were Organizer wise FU.
Organizer failed to run because of some file time stamp failure with its
files.
So I as per usual, for as long as I can remember I have to reinstall
Organizer again, and I'll have to do it again in the autumn...
Now, some of you are going to say, But Dave it's an Organizer problem, not
a RPCEmu problem.
Wrong! I've discussed this with Martin over the years...
And...
VRPC any of the versions I have and RISC OS 4.02 or 6.20 all run Organizer
without problems after the event.
I know VRPC gets its time from the Host OS (Windows), but RPCemu is
another matter.
VRPC is half a second behind the Windows clock (Updated daily)
RPCEmu is three seconds behind the Windows clock.
So to the bottom line question.
Why is RPCEmu causing this problem, and how to fix it.
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
As per usual, for as long as I can remember, ALL my RPCEmu installs that
use Organizer were Organizer wise FU.
Organizer failed to run because of some file time stamp failure with its
files.
So I as per usual, for as long as I can remember I have to reinstall
Organizer again, and I'll have to do it again in the autumn...
Now, some of you are going to say, But Dave it's an Organizer problem, not
a RPCEmu problem.
Wrong! I've discussed this with Martin over the years...
And...
VRPC any of the versions I have and RISC OS 4.02 or 6.20 all run Organizer
without problems after the event.
I know VRPC gets its time from the Host OS (Windows), but RPCemu is
another matter.
VRPC is half a second behind the Windows clock (Updated daily)
RPCEmu is three seconds behind the Windows clock.
So to the bottom line question.
Why is RPCEmu causing this problem, and how to fix it.
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: KYP West
In article <562119693cbbailey@argonet.co.uk>,
Brian <bbailey@argonet.co.uk> wrote:
> In article <e7f2052156.ricp@user.minijem.plus.com>,
> Richard Porter <ricp@minijem.plus.com> wrote:
> > On 22 Mar 2017 Tony Moore wrote:
> > > On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:
> > >> This looks to a really interesting site
> > > URL?
> > > Tony
> > I would hazard a guess that it might be http://www.kypwest.org.uk/
> That's correct. Sorry, I fired the email off before I remembered that I
> had forgotten to include it.
The site now seems to load but accessing individual geographic areas gets
the following,
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /kyp/southglos.
Reason: Error reading from remote server
Brian <bbailey@argonet.co.uk> wrote:
> In article <e7f2052156.ricp@user.minijem.plus.com>,
> Richard Porter <ricp@minijem.plus.com> wrote:
> > On 22 Mar 2017 Tony Moore wrote:
> > > On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:
> > >> This looks to a really interesting site
> > > URL?
> > > Tony
> > I would hazard a guess that it might be http://www.kypwest.org.uk/
> That's correct. Sorry, I fired the email off before I remembered that I
> had forgotten to include it.
The site now seems to load but accessing individual geographic areas gets
the following,
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /kyp/southglos.
Reason: Error reading from remote server
Re: [gccsdk] gccsdk/env/bin/zip
On 24/03/17 09:54, Ron wrote:
> My autobuilder has been failing at the package building stage with
> '/home/ron/gccsdk/env/bin no such file' or similar.
> In a terminal executing plain zip responds with zip information
> but executing gccsdk/env/bin gives same errors as the autobuilder gets.
> It appears to be an unresponsive binary.
> Does anyone know what the nature of it should be, is it a modified linux
> binary to suit sfixing etc, I guess a link to the native linux zip would
> be OK otherwise.
> I'm assuming it is for the cross-compiler to use as seen by the
> errors and it does not have an ,elf extension.
gccsdk/env/bin/zip is a linux binary with some RISC OS extensions to add
the ,xyz suffixes. It's produced by the native-zip package in the
autobuilder and is used to create the compiler and package archives.
Can you rebuild the package to see if that fixes it? Does the
gccsdk/env/bin folder exist and can you access it?
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> My autobuilder has been failing at the package building stage with
> '/home/ron/gccsdk/env/bin no such file' or similar.
> In a terminal executing plain zip responds with zip information
> but executing gccsdk/env/bin gives same errors as the autobuilder gets.
> It appears to be an unresponsive binary.
> Does anyone know what the nature of it should be, is it a modified linux
> binary to suit sfixing etc, I guess a link to the native linux zip would
> be OK otherwise.
> I'm assuming it is for the cross-compiler to use as seen by the
> errors and it does not have an ,elf extension.
gccsdk/env/bin/zip is a linux binary with some RISC OS extensions to add
the ,xyz suffixes. It's produced by the native-zip package in the
autobuilder and is used to create the compiler and package archives.
Can you rebuild the package to see if that fixes it? Does the
gccsdk/env/bin folder exist and can you access it?
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 24 March 2017
[gccsdk] gccsdk/env/bin/zip
My autobuilder has been failing at the package building stage with
'/home/ron/gccsdk/env/bin no such file' or similar.
In a terminal executing plain zip responds with zip information
but executing gccsdk/env/bin gives same errors as the autobuilder gets.
It appears to be an unresponsive binary.
Does anyone know what the nature of it should be, is it a modified linux
binary to suit sfixing etc, I guess a link to the native linux zip would
be OK otherwise.
I'm assuming it is for the cross-compiler to use as seen by the
errors and it does not have an ,elf extension.
Tried a svn update via mobile modem but got a reset by peer, probably
needs a fresh reboot at my end though.
TIA Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
'/home/ron/gccsdk/env/bin no such file' or similar.
In a terminal executing plain zip responds with zip information
but executing gccsdk/env/bin gives same errors as the autobuilder gets.
It appears to be an unresponsive binary.
Does anyone know what the nature of it should be, is it a modified linux
binary to suit sfixing etc, I guess a link to the native linux zip would
be OK otherwise.
I'm assuming it is for the cross-compiler to use as seen by the
errors and it does not have an ,elf extension.
Tried a svn update via mobile modem but got a reset by peer, probably
needs a fresh reboot at my end though.
TIA Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 23 March 2017
Pepperfish downtime last night
Hi,
Summary: We had some downtime, and we're working on a fix.
Services are currently up but may be slower than usual.
Expect moments of downtime throughout the day.
Last night, at approximately 0330 GMT, one of Pepperfish's
virtual machines suffered a kernel issue related to handling
of interrupts, causing it to become unresponsive. Sadly
this happened exactly as a database update was occuring,
causing some corrupted configuration files to be generated
and pushed to other servers. The upshot was that DNS
broke on our main server and on our secondaries. This had
a knock-on effect of also preventing mail being delivered
to us.
A second issue relating to very poor IO performance on one
of our virtual machine hosts has compounded the problem and
slowed a correct fix.
Given the extremely high uptime of the host (Over 1,200 days),
and the lack of anything it any of its logs that might
suggest why IO performance has become disappointing, we plan
on rebooting it (and thus all the virtual machines it hosts)
at some point today. This will mean the following services
will be down:
- ssh access to 'platypus'
- Web server
- IMAP server
- Mailing list delivery server
- One incoming mail server
- One DNS server
Secondary servers hosted elsewhere should receive and store
any email that is delivered while this happens; nothing
should be lost.
Apologies for the disruption.
B.
Summary: We had some downtime, and we're working on a fix.
Services are currently up but may be slower than usual.
Expect moments of downtime throughout the day.
Last night, at approximately 0330 GMT, one of Pepperfish's
virtual machines suffered a kernel issue related to handling
of interrupts, causing it to become unresponsive. Sadly
this happened exactly as a database update was occuring,
causing some corrupted configuration files to be generated
and pushed to other servers. The upshot was that DNS
broke on our main server and on our secondaries. This had
a knock-on effect of also preventing mail being delivered
to us.
A second issue relating to very poor IO performance on one
of our virtual machine hosts has compounded the problem and
slowed a correct fix.
Given the extremely high uptime of the host (Over 1,200 days),
and the lack of anything it any of its logs that might
suggest why IO performance has become disappointing, we plan
on rebooting it (and thus all the virtual machines it hosts)
at some point today. This will mean the following services
will be down:
- ssh access to 'platypus'
- Web server
- IMAP server
- Mailing list delivery server
- One incoming mail server
- One DNS server
Secondary servers hosted elsewhere should receive and store
any email that is delivered while this happens; nothing
should be lost.
Apologies for the disruption.
B.
Pepperfish downtime last night
Hi,
Summary: We had some downtime, and we're working on a fix.
Services are currently up but may be slower than usual.
Expect moments of downtime throughout the day.
Last night, at approximately 0330 GMT, one of Pepperfish's
virtual machines suffered a kernel issue related to handling
of interrupts, causing it to become unresponsive. Sadly
this happened exactly as a database update was occuring,
causing some corrupted configuration files to be generated
and pushed to other servers. The upshot was that DNS
broke on our main server and on our secondaries. This had
a knock-on effect of also preventing mail being delivered
to us.
A second issue relating to very poor IO performance on one
of our virtual machine hosts has compounded the problem and
slowed a correct fix.
Given the extremely high uptime of the host (Over 1,200 days),
and the lack of anything it any of its logs that might
suggest why IO performance has become disappointing, we plan
on rebooting it (and thus all the virtual machines it hosts)
at some point today. This will mean the following services
will be down:
- ssh access to 'platypus'
- Web server
- IMAP server
- Mailing list delivery server
- One incoming mail server
- One DNS server
Secondary servers hosted elsewhere should receive and store
any email that is delivered while this happens; nothing
should be lost.
Apologies for the disruption.
B.
Summary: We had some downtime, and we're working on a fix.
Services are currently up but may be slower than usual.
Expect moments of downtime throughout the day.
Last night, at approximately 0330 GMT, one of Pepperfish's
virtual machines suffered a kernel issue related to handling
of interrupts, causing it to become unresponsive. Sadly
this happened exactly as a database update was occuring,
causing some corrupted configuration files to be generated
and pushed to other servers. The upshot was that DNS
broke on our main server and on our secondaries. This had
a knock-on effect of also preventing mail being delivered
to us.
A second issue relating to very poor IO performance on one
of our virtual machine hosts has compounded the problem and
slowed a correct fix.
Given the extremely high uptime of the host (Over 1,200 days),
and the lack of anything it any of its logs that might
suggest why IO performance has become disappointing, we plan
on rebooting it (and thus all the virtual machines it hosts)
at some point today. This will mean the following services
will be down:
- ssh access to 'platypus'
- Web server
- IMAP server
- Mailing list delivery server
- One incoming mail server
- One DNS server
Secondary servers hosted elsewhere should receive and store
any email that is delivered while this happens; nothing
should be lost.
Apologies for the disruption.
B.
Subscribe to:
Posts (Atom)