[Dxspider-support] 1. Cluster started hanging several times a day. (David Spoelstra)

[Andy Cook G4PIQ]

I also found running on an external USB connected hard disk delivered much better I/O performance than running on the SD card. 

Andy, G4PIQ

Sent from my iPhone

> On 7 Mar 2019, at 13:44, gu6efb--- via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
> 
> Hi
>  
> The most likely reason is that the memory card holding the OS has worn out as it is only good for a limited amount of read/write cycles. DXspider puts a high read/write load on the card
> I had the same issue here with odd unexplainable  cluster failures and it was all down to the card.
> I now use a hard disk connected to the PI which has solved my issues .
>  
> 73 Keith GU6EFB
>  
> From: Dxspider-support [mailto:dxspider-support-bounces at tobit.co.uk] On Behalf Of Andy Scott via Dxspider-support
> Sent: 07 March 2019 11:36
> To: dxspider-support at tobit.co.uk
> Cc: Andy Scott
> Subject: [Dxspider-support] 1. Cluster started hanging several times a day. (David Spoelstra)
>  
> I cannot offer any conclusive feedback, but I have found, on raspberry pi, that a
> symptom of failure on my Pi is that the cluster service fails to communicate with clients on the user port. I have set a cron task to see if a login: prompt is received when telneting into the user port (note that you cannot rely on a telnet timeout, as communication with the port still works fine).  If it times out waiting for the login prompt, I kill the dxcluster process and restart the service - the cron script runs one minute before the normal dxspider cron to reconnect to the upstream server.
>  
> In doing so, I haven't needed to reboot the server, although this may still be needed from time to time if a different symptom presents.
>  
> The cron script is as follows, in case it helps anyone (the  /var/tmp folder should exist and be writeable):
> 
> #!/bin/bash
> #
> # First, capture the process ID for the dxspider server
> #
> PID=`pgrep cluster.pl` ;
> #
> # Test that we get a login prompt - not just that the telnet port is open
> # We're going to send  a login of _quit_  which will cause the cluster
> # to reject the login and close the session after writing a trace to
> # a temporary file that we can test later, checking its file length
> #
> echo "quit" | nc -w 2 [your server address] 7300 &> /var/tmp/dxtest
> grep -i "login" /var/tmp/dxtest
> test=$(cat < /var/tmp/dxtest)  || exit  #      exit if the file doesn't exist
> #
> #  If the tested file length is long enough to include "login" then all is working
> #
> if [ "${#test}" -lt 5 ]
>         then
>         # echo "The DXCluster has falledn over..."
>         kill -9 $PID ;
>         sleep 3
>         # echo 'reset by checkcluster.sh' | system-cat -t DXCluster -p warning ;
>         /etc/rc.d/rc.spider
>         sleep 1
>         logger "DXCluster reset -p warning"
> fi
> exit
> # The End
>  
>  
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20190307/6b4db563/attachment-0001.html>