Re: [Dorset] stdout and stderr redirection weirdness
Thanks, this all sounds like it'll be a very good idea. syslog is attractive, but I'm not sure this even has syslog. Or maybe I need to turn it on, I remember hearing something about it anyway. I'll figure it out and get back to you. At the moment I'm adding indexes to the database so it'll have to be a bit later on - this looks like it will take a few hours. Hamish On 18/02/2021 16:20, Keith Edmunds wrote: > OK, this is what I would do. Check whether logger (typically > /usr/bin/loggger) is installed on the system. If it is, create a script > that runs at boot as follows: > > #!/bin/ash [if /bin/bash is available, I'd use that] > > /usr/bin/logger -t xyzzy "SHELL=$SHELL" > /usr/bin/logger -t xyzzy "me=$(whoami)" > echo "test" > /tmp/me.log > /usr/bin/logger -t xyzzy "Status after file write: $?" > > What that does: > > - /usr/bin/logger makes entries in syslog, so no need to worry about >writing files > > - "-t xyzzy" will tag each syslog entry with "xyzzy". Of course you can >use any string, but that allows you to 'grep xyzzy /var/log/messages' >(or wherever syslog writes) > > - we check the shell (is it really ash?) > > - we check who we are (are we really root?) > > - we try writing to a file and report the status of doing so > > Just looking at your original post, the other thing I'd change is the > relative file reference. Rather than writing to ../stdout.log, just write > to /tmp/stdout.log. Better still: > > python3 ./main.py --id "NAS" 2>&1 | tee /usr/bin/logger -t xyzzy > > ...and have it sent to syslog. > > hth signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] stdout and stderr redirection weirdness
OK, this is what I would do. Check whether logger (typically /usr/bin/loggger) is installed on the system. If it is, create a script that runs at boot as follows: #!/bin/ash [if /bin/bash is available, I'd use that] /usr/bin/logger -t xyzzy "SHELL=$SHELL" /usr/bin/logger -t xyzzy "me=$(whoami)" echo "test" > /tmp/me.log /usr/bin/logger -t xyzzy "Status after file write: $?" What that does: - /usr/bin/logger makes entries in syslog, so no need to worry about writing files - "-t xyzzy" will tag each syslog entry with "xyzzy". Of course you can use any string, but that allows you to 'grep xyzzy /var/log/messages' (or wherever syslog writes) - we check the shell (is it really ash?) - we check who we are (are we really root?) - we try writing to a file and report the status of doing so Just looking at your original post, the other thing I'd change is the relative file reference. Rather than writing to ../stdout.log, just write to /tmp/stdout.log. Better still: python3 ./main.py --id "NAS" 2>&1 | tee /usr/bin/logger -t xyzzy ...and have it sent to syslog. hth -- Linux Tips: https://www.tiger-computing.co.uk/category/techtips/ -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] stdout and stderr redirection weirdness
On 18/02/2021 15:34, Keith Edmunds wrote: >> I'm finding that during startup piping and redirecting output doesn't >> work. This is using the ash shell from busybox. > By "during startup" do you mean system startup or your process startup? During system startup (that's the only way to get it running automatically). It piggybacks of the startup scripts for the webserver. Hamish signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] stdout and stderr redirection weirdness
> I'm finding that during startup piping and redirecting output doesn't > work. This is using the ash shell from busybox. By "during startup" do you mean system startup or your process startup? -- Linux Tips: https://www.tiger-computing.co.uk/category/techtips/ -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
[Dorset] stdout and stderr redirection weirdness
Hi all, I have yet another query relating to the NAS box. I suspect this issue is once again due to the weird setup and ancient software. I'm finding that during startup piping and redirecting output doesn't work. This is using the ash shell from busybox. I have the following in my script: python3 ./main.py --id "NAS" 2>&1 | tee ../stdout.log I have also tried simple redirects with > ../stdout.log, and | cat > ../stdout.log The file is created but always remains empty regardless of what I do. It does work when I SSH in and run commands though. Any ideas what might be causing this? I've never encountered this behaviour before. Thanks, Hamish signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Thursday, 18 February 2021 10:10:47 GMT Hamish McIntyre-Bhatty wrote: > I'm just finishing off my assignment, but should be able to look at > several WMT things this afternoon with luck. Hamish, I've just cracked the freezing problem, so you only need to look at the sockets error that I flagged on the Forum. As mentioned there that error doesn't seem to cause a problem, it just flags up an erroneous message received. I'd just like to know why. With regard to this issue, I suddenly remembered that Patrick had suggested using a separate thread to launch the MP3 Player, eg: threading.Thread(target=mp3_player_start).start() I had not tried that because I was under the erroneous impression that apscheduler launched the functions in a separate thread already; clearly not. Everything seems to be working fine now, although I need to test a few more things before I declare it ready for deployment. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Thursday, 18 February 2021 10:10:47 GMT Hamish McIntyre-Bhatty wrote: > I'm just finishing off my assignment, but should be able to look at > several WMT things this afternoon with luck. That would be appreciated. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
Yep, I saw it. I'm just finishing off my assignment, but should be able to look at several WMT things this afternoon with luck. Hamish On 18/02/2021 10:08, Terry Coles wrote: > On Thursday, 18 February 2021 09:48:20 GMT Hamish McIntyre-Bhatty wrote: >> Can't recall if you've tried this, but what if you replace the call to >> mpg123 with a call to echo or similar, just to narrow down whether it >> might be mpg123 that's causing the issue. >> >> If it only crashes with mpg123, perhaps there are some verbose or debug >> flags you can use for mpg123 to reveal more information? > I only just got this, despite the datestamp being 7 minutes earlier than my > post. > > Have you seen my latest? > signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Thursday, 18 February 2021 09:48:20 GMT Hamish McIntyre-Bhatty wrote: > Can't recall if you've tried this, but what if you replace the call to > mpg123 with a call to echo or similar, just to narrow down whether it > might be mpg123 that's causing the issue. > > If it only crashes with mpg123, perhaps there are some verbose or debug > flags you can use for mpg123 to reveal more information? I only just got this, despite the datestamp being 7 minutes earlier than my post. Have you seen my latest? -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Wednesday, 17 February 2021 13:32:19 GMT Terry Coles wrote: > In any case, the Bells Pi code uses the same approach, so how come that > works and the Music code doesn't? I think I've sussed this. :-) At least I think I know what is going wrong. In order to respond to commands coming in from the Webserver, I have a function called check_webserver_commands(). This periodically checks for data on the socket, parses it and calls the appropriate function; in this case restartmp3() (which calls mp3_player_start() ). To service this function, I added a line to apscheduler: sched.add_job(check_webserver_commands, 'interval', seconds=1, id='check_webserver_commands') The problem with this is that when the calling function takes a long time to return, I get an error (too many instances), so I added a line to the beginning of check_webserver_commands(): sched.pause_job(job_id='check_webserver_commands') # Suspend until current job is complete and one at the end: sched.resume_job(job_id='check_webserver_commands')# Restart checking for commands The problem is that the mp3_player_start() function doesn't return until the line: mp3_wait = mp3_player.wait() has completed (and never if the loop is active), so the sched.resume job never gets run. I used apscheduler to ensure that the check_webserver_commands() function would get called frequently, but without locking the program up during the intervals between each check, but it would seem that it doesn't successfully interrupt the mp3_player.wait() method. I need that method to tell me when the loop is completed, so can anyone suggest a better way to poll the check_webserver_commands() function or to make the mp3_player.wait() method more interruptible? Of course I may be wrong on my hypothesis, but when I put the sched.resume() method just before the call to restartmp3() the rest of the commands from the Webserver were recognised and serviced. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
Hi Terry, Can't recall if you've tried this, but what if you replace the call to mpg123 with a call to echo or similar, just to narrow down whether it might be mpg123 that's causing the issue. If it only crashes with mpg123, perhaps there are some verbose or debug flags you can use for mpg123 to reveal more information? Hamish On 17/02/2021 13:32, Terry Coles wrote: > On Tuesday, 16 February 2021 15:25:28 GMT Terry Coles wrote: >> So I'm kind of back where I started. > This morning I tried a variety of things to solve this; still to no avail. > > I've attached two more code fragments to this message; these are copied from > the latest version of the software on the Pis. The file > Minster_Bells_Software_Fragment.txt shows what I have on the Bells Pi to play > Change Rings on demand. Minster_Music_Software_Fragment2.txt shows the music > player version of this; which exhibits this problem. > > In order to get to the bottom of this I have: > > 1. Reduced the number of MP3 files in the Playlist directory to 1. > > 2. Re-written the code so that the line that uses glob to parse the files in > the directory is replaced with the actual path and filename to the first file. > > 3. Re-written the code to remove the while loop, to simplify things. > > 4. Commented out the lines that invoked the mpg123 player and terminated it > in the mp3_player_stop() function. > > Items 1 to 3 made no difference whatsoever to the behaviour; I still got the > freezing when I tried to restart the player/ > > With Item 4 the messages from the Webserver were responded to reliably but of > course no music was played. > > It would appear therefore that once the mpg123 player has been invoked and > then terminated, invoking it a second time makes the overall program > unresponsive. This I cannot understand because the "Music Playing" message > is > being printed, so presumably the lock up occurs at the line containing: > > mp3_wait = mp3_player.wait() > > I realise that the program will halt at that point until the mpg123 player > terminates, but the commands coming in are in new threads so they should > still > be responded to. (They have once.) > > In any case, the Bells Pi code uses the same approach, so how come that works > and the Music code doesn't? > > signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
