AWS wrote back saying the problem is not on their end, and they don’t troubleshoot 3rd party linux distros…
It seems they server is loving network connectivity, from the freepbx avahi-daemon[600]: Withdrawing address record for 172.31.20.124 on eth0. Because if I take a screenshot of the instance it shows its at the login prompt, I just can’t ping it or SSH in.
I installed the FreePBX ISO on VMware, and then exported that to an AMI image.
I also have another t2.micro running FreePBX without this issue, so its very strange.
AWS has an engineer looking at the problem now, who seems very knowledgeable, he said:
As the issue was with the private IP being released (at-least appears in messages), we checked the DHCP server of the instance to see if the DHCP client of the instance is sending the DHCPRequest or not. Based on the investigation and logs, I can confirm that the DHCP client of the instance ##### is requesting the private IP 172.xxx.xxx.xxx of the instance via DHCPRequest and get the renewal successfully via DHCPAck. Having said that, it appears that the IP address is not being removed, it just that avahi detected that the IP address has been removed, and is changing its internal state in response and we need to look further.
This is fixed, the problem was I changed the time zone from UTC to my local time zone, and the DHCP lease would time out before it renewed, because it thought it wasn’t time to renew due to the time zone change. Changing it back to UTC fixed the issue.
I highly recommend AWS EC2 for FreePBX as there have been no other issues.
I’ll second the recommending EC2, it’s worked swimmingly so far.
I also have what I’m quite sure was the same issue as you had, but did get the short straw on support techs from EC2, mostly just recommending using a more powerful instance type. But I’m pretty sure this is what’s going to fix my issue, didn’t ever occur to me that changing that time would’ve caused an issue and quite hate that it does.
Not sure if this matters too much for you but it will be inconvenient for sure to have all of our call logs and recordings having incorrect timestamps.
Did you end up just leaving it with UTC or did you find a way to get it all correct?
Following this topic if any solutions have come up… I have a production system running on EC2, I tried changing the time zone when I first set it up and ran into this issue, so I just left it on UTC. I do have a possible change coming up regarding Scheduled Pages and it would be much simpler if the system time was on local time…
Wow, the solution by @alexhfch saved me. I changed my time-zone on a new FreePBX v15 server running on AWS EC2 and every hour or so I’d lose connectivity. Setting it back to 0 did the trick.