MX "stuck" flushing input stream

[freddie]

MX on GNU/Linux connecting to Davis VP2 via Virtual VP.

Did a restart at 0906 UTC - log file was getting rather large after nearly 2 weeks of uptime!

Tailing the new log file, it looks as if MX is "stuck" flushing the input stream. MX not responsive to "CTRL-C" quit command. Diags file attached.

20150617-090704.txt

[freddie]

I've just checked Virtual VP for errors - and it appears that MX didn't connect to the station on restart. I'm not sure where it was getting the inputstream data from - but it appears there was an abundance of it, looking at the MXDiags log.

Virtual VP displayed further errors about buffer sizes being incorrect when I re-started MX the second time. At this point, Cumulus 1 (listening to VVP on a different port) lost its connection and restarted. So I think VVP had entered a confused state.

Virtual VP and MX now restarted and running okay. Note I had to forcibly stop MX using "kill" as the console was not responding to Ctrl-C. I guess it doesn't listen to the keyboard until the program has finished it's start-up tasks?

[steve]

I've just checked Virtual VP for errors - and it appears that MX didn't connect to the station on restart. I'm not sure where it was getting the inputstream data from - but it appears there was an abundance of it, looking at the MXDiags log.

It thinks it was connected successfully, and it was receiving (unrequested) LOOP packets. It continues to read and discard data at start up until the connection goes quiet, to make sure it's in a clean state when it starts issuing commands.

Note I had to forcibly stop MX using "kill" as the console was not responding to Ctrl-C. I guess it doesn't listen to the keyboard until the program has finished it's start-up tasks?

It sets up the signal handler thread as the very first thing it does, and while it's flushing the input stream it sleeps for 200ms between each character, so I don't know why that didn't allow the CTRL-C signal to be processed.

[freddie]

I've just checked Virtual VP for errors - and it appears that MX didn't connect to the station on restart. I'm not sure where it was getting the inputstream data from - but it appears there was an abundance of it, looking at the MXDiags log.

It thinks it was connected successfully, and it was receiving (unrequested) LOOP packets. It continues to read and discard data at start up until the connection goes quiet, to make sure it's in a clean state when it starts issuing commands.

Yes, I noticed on the VVP display something like "receiving 1045 out of 50 loop packets" - so was in a right old pickle!!

Note I had to forcibly stop MX using "kill" as the console was not responding to Ctrl-C. I guess it doesn't listen to the keyboard until the program has finished it's start-up tasks?

It sets up the signal handler thread as the very first thing it does, and while it's flushing the input stream it sleeps for 200ms between each character, so I don't know why that didn't allow the CTRL-C signal to be processed.

Yes, I thought you would've set up a listener as one of the first tasks - hence my puzzlement at the behaviour. When trying to terminate MX I made several (tens of) CTRL-C attempts before using "kill".

[steve]

Yes, I noticed on the VVP display something like "receiving 1045 out of 50 loop packets" - so was in a right old pickle!!

I was going to suggest that it would have possibly sorted itself out eventually once VVP stopped sending the loop packets, but from that it looks like you would still be waiting