Re: [Dorset] Raspberry Pi Issue with hwclock
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 Python, or the electronics, but you're clearly having a tough time of it learning piecemeal from a hotchpotch of problems rather than a planned gentle introduction. Well that's me told :-) I learnt from two of Unix's creators, Kernighan and Pike's _The Unix Programming Environment_, http://amzn.to/16SVwhD and it's what I still recommend, though the price seems to have kept pace with inflation over the decades. There are second-hand ones available though. That's the nicest RTFM I've ever had :-) The problem I have is that I was never (and never will be) a software developer. I have written snippets of code in various languages on both Unix and Windows platforms for well over 30 years, but I have never sat down to intensively write code; it has always been a means to make the electronics work. Taking the quoting of the strings in 'echo', every language and platform that I have ever used has had a different policy on strings (single quotes, double quotes, brackets and combinations thereof). I only mentioned the quoting problem because I had done what I usually did for strings and then only realised it was wrong when I read your response (at a time when I would be unable to test it for a few days). With 'exec' the story was different because I had never noticed this command before. I read the man page when Bob mentioned it and as usual learnt little because of the terminology used. I then looked around and stumbled across a page that made some kind of sense. It was only when you said that my definition was wrong that I went back and realised that I had found a definition of exec(), not exec. I do read books and online material to find out what I need to do, but since I never trained as a software engineer, I frequently end up more confused than when I started; hence my Janet and John queries on this list. Coupled with the fact that I literally only do this sort of thing a few times a year (when the hardware needs a platform to operate on), I suspect that I'd forget what I learned by the time I needed it. Anyway. I'm still grateful for any help given and I'll try not to be so dumb in the future ;-( Even for those of us that have been trained in programming and have created things in software, this has been a learning experience, and I am always grateful to Ralph and others for their explanations. It's come a long way since PDP-8 Assembler and Primix, that's for sure. Peter -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 you're clearly having a tough time of it learning > piecemeal from a hotchpotch of problems rather than a planned gentle > introduction. Well that's me told :-) > I learnt from two of Unix's creators, Kernighan and Pike's _The Unix > Programming Environment_, http://amzn.to/16SVwhD and it's what I still > recommend, though the price seems to have kept pace with inflation over > the decades. There are second-hand ones available though. That's the nicest RTFM I've ever had :-) The problem I have is that I was never (and never will be) a software developer. I have written snippets of code in various languages on both Unix and Windows platforms for well over 30 years, but I have never sat down to intensively write code; it has always been a means to make the electronics work. Taking the quoting of the strings in 'echo', every language and platform that I have ever used has had a different policy on strings (single quotes, double quotes, brackets and combinations thereof). I only mentioned the quoting problem because I had done what I usually did for strings and then only realised it was wrong when I read your response (at a time when I would be unable to test it for a few days). With 'exec' the story was different because I had never noticed this command before. I read the man page when Bob mentioned it and as usual learnt little because of the terminology used. I then looked around and stumbled across a page that made some kind of sense. It was only when you said that my definition was wrong that I went back and realised that I had found a definition of exec(), not exec. I do read books and online material to find out what I need to do, but since I never trained as a software engineer, I frequently end up more confused than when I started; hence my Janet and John queries on this list. Coupled with the fact that I literally only do this sort of thing a few times a year (when the hardware needs a platform to operate on), I suspect that I'd forget what I learned by the time I needed it. Anyway. I'm still grateful for any help given and I'll try not to be so dumb in the future ;-( -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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, although I don't get the message, I do get the O/P of rdate, > which is something along the lines of 'clock adjusted by xyz seconds'. You're running `rdate -v' that, if I'm reading the right source, puts that message to stdout. http://openrdate.cvs.sourceforge.net/viewvc/openrdate/openrdate/src/rdate.c?revision=1.1=markup#l164 > Is there some mechanism that directs the O/P of echo to stdout once > the system has booted but to somewhere else while it is being booted? echo(1) always goes to stdout. It and other commands just blindly write(2) to file descriptor 1, trusting that it has been set up to where something else wants it to go. /etc/rc.local could be run with its file descriptor 1 not connected to what you're seeing, e.g. a TTY, but in that case I'd expect rdate's writing to FD 1 to also disappear too. > Finally, I also realised last night that all the examples of echo that > I had seen were written as echo foo, whereas I have written echo > "foo". Could this have any bearing? Probably not, depending what you had for the `foo'. It would be helpful to see the contents of /etc/rc.local where your echo and rdate reside. 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 you're clearly having a tough time of it learning piecemeal from a hotchpotch of problems rather than a planned gentle introduction. I learnt from two of Unix's creators, Kernighan and Pike's _The Unix Programming Environment_, http://amzn.to/16SVwhD and it's what I still recommend, though the price seems to have kept pace with inflation over the decades. There are second-hand ones available though. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 you to wrap the arguments of the target command so that > the underlying code receives them correctly. I don't recognise that description. :-) Which man page? On my system, there's $ man -f exec | sort -V exec (1p)- execute commands and open, close, or copy file... exec (3p)- execute a file exec (3) - execute a file exec (n) - Invoke subprocesses $ But yours could be different. The first line of `man exec' will give the section name in parenthesis. > My rdate command includes one switch and one argument, so how come it > works without the exec prefix? You're so off track that I'll ignore the question. :-) If you've a three-command shell script that does #! /bin/sh who -b id -G date -d yesterday +%Y-%m-%d then when sh is told to run it, it reads in the file. That's a single Linux process doing that work. There is no way for a process to ask the kernel to create a new process to run who(1), say. Instead, there are two distinct system calls that sh uses to get the kernel to run who. (This was a fundamental distinction between Unix and many other OS at the time that gave Unix some of its unique attributes that made it popular.) First, sh uses fork(2) to have the kernel duplicate it. There are now two sh processes running: the original that made the request to the kernel; and the "child" of it that has been created. The first still has its original process ID, the second has a new one that wasn't already in use. The return value from fork() in the parent is the child's process ID so it can distinguish it from other children, e.g. to kill(2) it. But the same call to fork() also returns in the child and that return value is 0; an invalid PID. This allows the source code to do alternate things in the parent and child. pid = fork(); if (pid == -1) err(1, "fork failed"); if (pid) return; /* Only the child continues from here. */ That's the first half of the story. sh can now create many sh, each of which can create yet more. But for running the script, the child will use the execve(2) system call to execute the given file, passing on the specified arguments and environment variables, in this case /usr/bin/who. The kernel keeps the child sh's process ID, and quite a few other bits of it like open files, but replaces the running machine code with that from who, arranging for execution to wind its way towards main(). Meanwhile, parent sh will use the wait(2) system call to go to sleep until the kernel returns to it with news of its child, e.g. that it has _exit(2)'d. sh starts all over again with the next line for id(1) and the fork, execve, wait cycle repeats. In the sh's language, placing "exec" at the start of the command is telling sh to skip the fork stage. It still calls execve(), but the kernel isn't replacing the child shell; it's the original shell that gets trampled with a new executable. If the above script has the second command changed to "exec id -G" then when id(1) finishes and _exit()s, it's the parent of the sh that was running the script that returns from wait() with news that its child, that it started as a sh but ended up as id, has exited. Thus date(1) isn't run. A minor optimisation, still useful on small machines, is to therefore augment the last command a shell script runs, if it's an external one requiring a fork+exec, with exec, saving the fork and its overhead of creating a new process. That's why Bob said to replace rdate ... exit $? with exec rdate ... Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 the > references I've found for exec, (including its man page), the command allows > you to wrap the arguments of the target command so that the underlying code > receives them correctly. My rdate command includes one switch and one > argument, so how come it works without the exec prefix? In this case the exec is entirely optional. Force of habit on my part from years of working on tightly constrained machines. Exec is a shell built in command so better often to check the particular shells man page. Anyway the relevant part of the manual is "If command is specified, it replaces the shell.". So when you run a command without the exec prefix the parent shell creates a subshell clone of itself (an expensive operation), then this subshell runs the command by exec'ing it. The exec prefix tells the parent shell not to bother with the subshell creation but to directly exec the target command itself. The exec system call basically replaces the existing process (in this case the shell or subshell) with the new target command (rdate) with the target inheriting all the original processes resources including it's process ID. The cost of that "creating a subshell clone" used to be really horrendous, which was why BSD went to the trouble of creating the vfork() system call in an attempt to reduce this overhead. The vfork man page has some interesting history for people into kernel mechanics. -- Bob Dunlop -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 time to dash this off and no time to fire up the Pis. On Saturday, 16 September 2017 20:21:17 BST Ralph Corderoy wrote: > If you're using `echo foo' then that goes to standard out, stdout. But > that might be being discarded. You could try standard error, stderr, > instead with `echo foo >&2'. But that might be being discarded too. > Use One thing that struck me though. I understand what you are saying here but 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. Also, I know the command is being executed correctly at boot up, because, although I don't get the message, I do get the O/P of rdate, which is something along the lines of 'clock adjusted by xyz seconds'. Also the clock is right :-) Is there some mechanism that directs the O/P of echo to stdout once the system has booted but to somewhere else while it is being booted? Finally, I also realised last night that all the examples of echo that I had seen were written as echo foo, whereas I have written echo "foo". Could this have any bearing? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 page), the command allows you to wrap the arguments of the target command so that the underlying code receives them correctly. My rdate command includes one switch and one argument, so how come it works without the exec prefix? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 out, stdout. But that might be being discarded. You could try standard error, stderr, instead with `echo foo >&2'. But that might be being discarded too. Use echo foo `date` >>/tmp/i-am-terry to ensure your commands are running at all by checking that file afterwards. Once you know they are because you see some output then you can be adventurous. ls -l /proc/self/fd >>/tmp/i-am-terry That will capture where your stdout, 1, and stderr, 2, are going. Perhaps /dev/null. The results would be of interest. And then there's two more to try. echo this is tty >/dev/tty echo this is console >/dev/console You could just put them all in rc.local at once and see what happens. echo terry: stdout echo terry: stderr >&2 echo terry: tmp file `date` >>/tmp/i-am-terry ls -l /proc/self/fd >>/tmp/i-am-terry echo this is tty >/dev/tty echo this is console >/dev/console Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 delimit the "test" command that performs various tests on it's arguments before exiting with the result. What you've coded there is a test of whether the string "rdate -v 192.168.0.2" is non-zero length. Skip the [] and run the command directly in the if structure. if rdate -v 192.168.0.2 ; then exit 0 else exit 1 fi The return code of the last command is available in the variable $? so you could simplify this to. rdate -v 192.168.0.2 exit $? Or even simpler as this is the last command. exec rdate -v 192.168.0.2 HTH -- Bob Dunlop -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 RFC 868 time server; just what you want. Ralph, That appears to work beautifully ;-) I have a couple more questions before I can finish the job: 1.I put the command into rc.local to ensure it executed at boot up, with a 30 second delay just before it to ensure that sumppi had started before it was interrogated. So that future maintainers might have a clue what is going on I put a message about the reason for the delay just before the if structure containing the command. The trouble is that this message is not echoed to the console during boot-up but it is if I run rc.local explicitly from the command line. How do I get the message to show up in the boot messages. 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 However, the command doesn't seem to execute. It does if I just put it in without testing for the result. Is it possible to do this with this command? BTW. Thanks for your help (again). -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 as a built-in service of inetd[1](8)' and is on > port 37 by default. Yes. inetd has been replaced by xinetd these days. They both listen on a bunch of ports and when a connection happens typically hand off the connection to another program that's unrelated to them to do the work. xinetd appears to be packaged for Raspbian. I guess the Debian folk have made it subserviant to systemd in some manner. 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 RFC 868 time server; just what you want. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 Raspbian Stretch and gradually added the various packages and config settings to see what broke it. Everything worked fine until I configured the remote Pi (buttspi) to read time from the NTP Server on the master (sumppi). I had been running with NTP installed on both Pis, and sumppi configured to broadcast on the network's broadcast address. The RTC kept perfect time. I then enabled 'broadcastclient' on buttspi and on the next reboot the time on sumppi was reset to the same (or nearly the same) as buttspi. Unless anyone can spot the obvious howler, then I'm ready to try rdate, as you suggested. With that in mind, I installed rdate on buttspi, isolated the Pi from the local network, plugged in a WiFi adaptor and typed: sudo rdate -ncv 0.debian.pool.ntp.org and it worked! I then set up the system as it will be in situ (without the WiFi adaptor) and typed: sudo rdate -v 192.168.0.2 and got connection refused. I've googled for the 'trivial' instructions for setting up the time port, but can't really see what I need to do. Apparently, (according to the rdate man page), the time source 'is usually implemented as a built-in service of inetd[1](8)' and is on port 37 by default. Do I need to enable that port or is it slightly more complicated than that? -- Terry Coles [1] http://www.huge-man-linux.net/man8/inetd.html -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 might be triggering something similar > in the kernel by reporting NTP-time is sync'd; that's the "11 minutes" > that you've been seeing. > https://unix.stackexchange.com/questions/285129/switch-off-11-minute-kernel-> > mode I was thinking that this was happening, but I wasn't sure exactly why. > I don't know if dmesg(1) shows this read/write to the RTC. I'll have a look. I'm waiting to see if disabling the NTP server has truly fixed this before I do anything else. > Am I right in thinking that you want the Pi to treat the RTC as > perfection, never wrong, and never adjust it unless you manually set the > RTC's time? That the RTC time should be used at boot, and thereafter > the Pi's own clock maintains the time and the RTC is read or written > again. Any divergence doesn't matter because the Pi will reboot > tomorrow and the RTC read afresh. That's exactly what we want to do. We don't mind if the RTC is a bit wrong (ie a minute or two, so that we can tie readings to events), but we want all Pis to have the same time. Eventually there may be three, four or even five Pis in this system, depending on how many Butts sites we end up with and then there will be the webserver to provide staff control and Visitor viewing. The webserver may end up running on the 'master' Pi or the Audio Guide and Quiz webserver; we haven't done that bit of system design yet. > 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. That looks like a good way to go and a lot less 'messy' than running an NTP server. I'll have a look into it. Thanks for your help again. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 /etc/init.d/hwclock.sh. Then ntpd might be triggering something similar in the kernel by reporting NTP-time is sync'd; that's the "11 minutes" that you've been seeing. https://unix.stackexchange.com/questions/285129/switch-off-11-minute-kernel-mode I don't know if dmesg(1) shows this read/write to the RTC. Am I right in thinking that you want the Pi to treat the RTC as perfection, never wrong, and never adjust it unless you manually set the RTC's time? That the RTC time should be used at boot, and thereafter the Pi's own clock maintains the time and the RTC is read or written again. Any divergence doesn't matter because the Pi will reboot tomorrow and the RTC read afresh. 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. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 > master Pi (the same one that has the clock), I'm not sure if it's an issue > or not. Yesterday, I removed the code in ntp.config to set up the NTP server on the 'master' pi and a few minutes ago the time was accurate to within 1 second. Obviously, I need to monitor it for a bit longer, but it looks like something is interfering with the clock when the server is running. I think that it's likely I've found the problem and I need to work out how to prevent the NTP server affecting the time on it's own machine. Anyone got any ideas? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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. :-) :-) I realised that. It's what I'd have to do to get the clean installation to a fully working sumppi that I was referring to. > I suppose the slaves could send their readings to the master to log > centrally, then they wouldn't care what time it was. :-) The actual software that is monitoring the levels does that, but we want the logs so we can see what went wrong and when. For example the electrics at the WMT are sadly in need of an overhaul and the power trips from time to time. It's useful to known when this happens, especially since the Pi features a fake hwclock which picks up from where it left off, which is useful, but confusing in these circumstances. Probably more relevant to normal ops is knowing that the Butts pump cut out at the right time; when the butts were nearly full. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 of > water in the sump at 10:45 on the 11th and at the same time the Butts > Pi is recording 100 mm of water in the butts at 17:50 on the 10th. I suppose the slaves could send their readings to the master to log centrally, then they wouldn't care what time it was. :-) Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 start serving it from the off. Yes. But we can live with this if we have to. > > The bad news is that I have got very unreliable timekeeping from the > > realtime clock on the master Pi. Sometimes it appears to be keeping > > time, sometimes it gains or loses several minutes in an hour. > > Start with a freshly downloaded Raspbian image, do the minimum required > from the instructions to use the RTC, do not add NTP, etc. Just see if > the RTC, the kernel, and userspace play well together over the hours and > days. Then you'll know it's your tinkering that's the problem. It > still smells like multiple parties are trying to adjust for creep. I'm kind of doing the other thing at the moment; eg disabling NTP and then using the hwclock-set script from the Bells system if that doesn't work. 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. Having said that, I did upgrade both Pis from Jessie to Stretch, so I may end up having to start from scratch. > Did I ask this before? Why do the Pis need to be in sync, and to what > accuracy? Do they need to know the actual time on the audience's > wrists, or just be in agreement with each other that it's 15 minutes > since they last gave us a twirl? Both Pis are taking readings and logging them to a file. It is really confusing if the Sump Pi says that there was 700 mm of water in the sump at 10:45 on the 11th and at the same time the Butts Pi is recording 100 mm of water in the butts at 17:50 on the 10th. If NTP proves to be the problem and I'm not able to suss out why, then we'll write a script to run at boot-up on the Butts Pi to read the system clock on the Sump Pi and then set its own clock accordingly. It's not hard to do, I suspect, but NTP seemed to be designed to do that, so that's what we did. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Raspberry Pi Issue with hwclock
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 got very unreliable timekeeping from the > realtime clock on the master Pi. Sometimes it appears to be keeping > time, sometimes it gains or loses several minutes in an hour. Start with a freshly downloaded Raspbian image, do the minimum required from the instructions to use the RTC, do not add NTP, etc. Just see if the RTC, the kernel, and userspace play well together over the hours and days. Then you'll know it's your tinkering that's the problem. It still smells like multiple parties are trying to adjust for creep. Did I ask this before? Why do the Pis need to be in sync, and to what accuracy? Do they need to know the actual time on the audience's wrists, or just be in agreement with each other that it's 15 minutes since they last gave us a twirl? Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
[Dorset] Raspberry Pi Issue with hwclock
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 news is that I have got very unreliable timekeeping from the realtime clock on the master Pi. Sometimes it appears to be keeping time, sometimes it gains or loses several minutes in an hour. One problem is that everything I try necessitates a delay of at least an hour or so before anything useful can be seen (and of course if it is keeping time then I have to wait even longer) ;-( The setup I have is that the master Pi has a RASClock purchased from ModMyPi, but sourced from Afterthought Software. The setup instructions are here: https://afterthoughtsoftware.com/products/rasclock. I originally posted on the ModMyPi Forum about this, but the response was fairly poor. One issue I had was that we have updated the installation on the two Pis to Raspbian Stretch; the last time I used one of these it was for the Bells software on Jessie. Now to the question. I was comparing the hwclock-set file on my Bells SD Card with the same file on the Sump Pi SD Card and I noticed a difference. The Bells config is missing two changes from the Afterthought website: * Comment out or remove the two lines which contain --systz buts that 's version that works! 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 master Pi (the same one that has the clock), I'm not sure if it's an issue or not. Does anyone have any thoughts on this? I'll quite happily fiddle with the settings, to try to fix this, but I'd like to know what I'm doing and the inherent delay means that it could be days before I know if I've fixed it. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
