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
