FWIW its worth if others find themselves in a similar situation, we found a way round the problem on Monday when we wanted to fly back from Portoroz, Slovenia to Biggin. Around 13.00 our “normal” 30 minutes +/- slot delay suddenly turned into 9.5 hours and we found the news about the ATC issues in the UK. So we immediately refiled to Ostende with the intention of spending the night in Bruges and flying back VFR across the channel in the morning. But when we got handed to Maastricht control, on the off chance, we asked them to coordinate with London Control for a possible diversion to Biggin, and, after 15 minutes of waiting, amazingly it worked. From what they said it would have been easier if I had been smart enough to list Biggin as an alternate on the FPL. I did offer to cancel IFR at the London FIR boundary, but it wasnt necessary, they cleared me IFR all the way.
lionel wrote:
in the “letsencrypt” cronjob scenario, renewal happens well before expiry, so there is ample time for a human to intervene
a cronjob on a properly setup unix-like machine (often GNU/Linux these days) will send an email to the relevant person when it fails…
Well-configured linux machines will run for a very long time. I’ve had machines that configured and patched and rebooted themselves for years without human intervention. I’ve had others that were simply left alone and ran for over a decade.
How did you manage the UK GAR ?
boscomantico wrote:
How did you manage the UK GAR ?
I already had a GAR in place for the Portoroz Biggin flight. I didn t cancel it, though at the time we departed Portoroz I had not thought of using a diversion. IN any event there is permanent customs and police at Biggin and they didnt even bother to look at my passport.
I’ve had others that were simply left alone and ran for over a decade.
I’ve had that too… until you get to stuff like external comms and certificates, etc. Stuff which others keep messing with. Funny that my company’s HTTPS cert has just broken… yet again 
I did offer to cancel IFR at the London FIR boundary, but it wasnt necessary, they cleared me IFR all the way.
LC basically toss the IFR flight plan in the bin on the way back to the UK (if going only to or near the s. coast).
How did you manage the UK GAR ?
I file these even if not filing to land in the UK, but if I might divert
I’ve read that NATS know that some FPs break their code so they have a filter for these. Looks like some French airline filed an FP which that filter didn’t pick up 
Buckerfan wrote:
From what they said it would have been easier if I had been smart enough to list Biggin as an alternate on the FPL.
The proper way to do this is to add RIF/EKGB in section 18 of the flight plan. (RIF = Reclearance in flight.) This is used when you must file to an intermediate stop because you can’t safely or reliably plan to your intended destination but you reasonably expect circumstances to change in flight. (Fuel requirements, shortcuts, wind…) You can also include a route to the other destination.
Peter wrote:
I’ve read that NATS know that some FPs break their code so they have a filter for these. Looks like some French airline filed an FP which that filter didn’t pick up
I don’t know what to make of that information. I defies belief.
Poor inputs control can result with software crashes and it happens due to poor programming skills resulting with different memory management issues. However, it’s hard to believe that such bug can repeatedly crash software in retries of processing such faulty data, obviously a software with very low resilience and high data dependency.
Surely Java has no memory management issues… it has garbage collection which is a perfect solution to crap programming
But this issue seems simpler. Reading between the lines, some flight plan constructs crash the (old) NATS code so they catch these and handle them separately. But they can catch only the ones they know about, and somebody created a new one.
This is a great DOS vulnerability, due to the ease of injecting flight plans into the system.
Emir wrote:
Poor inputs control can result with software crashes and it happens due to poor programming skills resulting with different memory management issues. However, it’s hard to believe that such bug can repeatedly crash software in retries of processing such faulty data, obviously a software with very low resilience and high data dependency.
Emir, yeah, *%it happens, that’s why you have 24×7 support – where have they been? Trying to re-run the task against the same failing job again and again?
The OPS part of things bothers me somewhat…
