On 18/09/17 14:37, Terry Coles wrote:
On Sunday, 17 September 2017 11:52:00 BST Ralph Corderoy wrote:
BTW, this is all fairly basic shell scripting stuff, e.g. quoting with
"" or '' or ``, with a little knowledge of how Unix works. I know you
think you don't need to know it, and can stick with
On Sunday, 17 September 2017 11:52:00 BST Ralph Corderoy wrote:
> BTW, this is all fairly basic shell scripting stuff, e.g. quoting with
> "" or '' or ``, with a little knowledge of how Unix works. I know you
> think you don't need to know it, and can stick with Python, or the
> electronics, but
Hi Terry,
> the messages are being echoed when I simply type 'sudo /etc/rc.local'
> in a shell but not when it is executed at boot up.
Another command for your rc.local test is
logger -t terry this is logger
> Also, I know the command is being executed correctly at boot up,
> because,
Hi Terry,
> Bob Dunlop wrote:
> > exec rdate -v 192.168.0.2
>
> This only occurred to me last night. When I put the command into my
> script without preceding it with 'exec' it appears to work. According
> to the references I've found for exec, (including its man page), the
> command allows
Hi,
On Sun, Sep 17 at 07:18, Terry Coles wrote:
> On Saturday, 16 September 2017 19:09:27 BST Bob Dunlop wrote:
> > exec rdate -v 192.168.0.2
>
> This only occurred to me last night. When I put the command into my script
> without preceding it with 'exec' it appears to work. According to
Ralph,
Thanks for all the information. I'll probably not get round to looking at it
for a few days because I shortly have to set off for the Midlands to collect
my mother, who is staying with us for the week. I'll give it a whirl to see
what's, what. Just at the moment though, I only have
On Saturday, 16 September 2017 19:09:27 BST Bob Dunlop wrote:
> exec rdate -v 192.168.0.2
This only occurred to me last night. When I put the command into my script
without preceding it with 'exec' it appears to work. According to the
references I've found for exec, (including its man
Hi Terry,
> Anyone know how to get the message to delay?
Assuming "display". :-) I don't have a Raspbian to poke about, but I'm
assuming /etc/init.d/rc.local exists and it's what runs /etc/rc.local if
it's executable. Make sure it is.
If you're using `echo foo' then that goes to standard
On Saturday, 16 September 2017 19:09:27 BST Bob Dunlop wrote:
> exec rdate -v 192.168.0.2
Thanks. I copied some code from somewhere else ;-(
Anyone know how to get the message to delay?
--
Terry Coles
--
Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00
Meets,
Hi,
On Sat, Sep 16 at 06:16, Terry Coles wrote:
...
> 2. I tried to put the command into an if structure to test to ensure that it
> worked, eg
>
> if [ "rdate -v 192.168.0.2" ]; then
> exit 0
> else
> exit 1
> fi
That's not the way to test the outcome of a command. The [ ] actually
On Saturday, 16 September 2017 16:53:24 BST Ralph Corderoy wrote:
> Some ports provide such trivial functionality that inet and xinetd do
> the work themselves, and TCP and UDP port 37 is one of those.
> https://en.wikipedia.org/wiki/Xinetd gives some more detail, and its
> worked example is an
On Saturday, 16 September 2017 17:05:27 BST Ralph Corderoy wrote:
> Out of curiousity, what rebooted?
Both devices. They both derive their power from the same 19 V PSU.
--
Terry Coles
--
Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00
Meets, Mailing list, IRC,
Hi Terry,
> The RTC kept perfect time. I then enabled 'broadcastclient' on [the
> client] and on the next reboot the time on [the server] was reset to
> the same (or nearly the same) as [the client].
Out of curiousity, what rebooted?
Cheers, Ralph.
--
Next meeting: Bournemouth, Tuesday,
Hi Terry,
> sudo rdate -v 192.168.0.2
>
> and got connection refused.
That tells you that the remote network stack replied saying there was
nothing that was listening on the port you tried to contact.
> Apparently, (according to the rdate man page), the time source 'is
> usually implemented
On Monday, 11 September 2017 15:14:43 BST Ralph Corderoy wrote:
> You might find an rdate(1) from the slave is simpler at boot time. I
> don't know if Raspbian provides a server for the `time' port, but it's a
> trivial thing.
Well. I took your advice and started from a clean installation of
On Monday, 11 September 2017 15:14:43 BST Ralph Corderoy wrote:
> More than one thing, I expect. It's possible your system is trying to
> adjust the RTC based on the divergence it notices between boot-up and
> shutdown. /etc/adjtime can be a sign of that, or
> /etc/init.d/hwclock.sh. Then ntpd
Hi Terry,
> but it looks like something is interfering with the clock when the
> server is running.
More than one thing, I expect. It's possible your system is trying to
adjust the RTC based on the divergence it notices between boot-up and
shutdown. /etc/adjtime can be a sign of that, or
On Sunday, 10 September 2017 12:32:49 BST Terry Coles wrote:
> I've been reading the man page for hwclock to see what --hctosys and --systz
> do and have been struggling to see how relevant this might be and I note
> the reference to NTP. Bearing in mind that the NTP server is running on the
>
On Sunday, 10 September 2017 18:01:50 BST Ralph Corderoy wrote:
> > There's a fair amount of work gone into configuring the system at the
> > moment and I'd rather not have to rebuild it if I don't have to.
>
> I didn't mean trash your existing SD card's content, but use a spare
> one. :-)
:-)
Hi Terry,
> There's a fair amount of work gone into configuring the system at the
> moment and I'd rather not have to rebuild it if I don't have to.
I didn't mean trash your existing SD card's content, but use a spare
one. :-)
> It is really confusing if the Sump Pi says that there was 700 mm
On Sunday, 10 September 2017 16:24:51 BST Ralph Corderoy wrote:
> > this makes us wait for up to 10 minutes before the system syncs, but
> > when it does the two clocks are exactly the same.
>
> That's pretty lousy. It would be nice for the NTP server to know to
> trust the RTC and be happy to
Hi Terry,
> this makes us wait for up to 10 minutes before the system syncs, but
> when it does the two clocks are exactly the same.
That's pretty lousy. It would be nice for the NTP server to know to
trust the RTC and be happy to start serving it from the off.
> The bad news is that I have
Guys,
I'm still having problems with our installation at the WMT. I got NTP to work
on the
remote Pi by using Ralph's ntp-wait work-round; this makes us wait for up to 10
minutes
before the system syncs, but when it does the two clocks are exactly the same.
That's the good news. The bad
23 matches
Mail list logo
