These VMs don’t exist anymore. They don’t show up in fly status. The code that’s showing in the stacktraces isn’t even in our codebase anymore. In a recent deploy we removed predis/predis and also laravel/horizon, because we don’t want to use Redis anymore. I also removed the Redis app that it’s trying to connect to. Somehow there are still VMs in the background that are trying to connect to Redis?? Would love some help on this, we’re burning through our Sentry limits!
If a dev could at least kill them, that would be great.
I can still see the logs of the “correct” VM by selecting it from the dropdown in the dashboard, but other than that the logs are flooded by “ghost” VMs.
#!/usr/bin/env sh
if [ $# -gt 0 ];then
# If we passed a command, run it as root
exec "$@"
else
/usr/bin/php /var/www/html/artisan config:cache --no-ansi -q
/usr/bin/php /var/www/html/artisan route:cache --no-ansi -q
/usr/bin/php /var/www/html/artisan view:cache --no-ansi -q
exec supervisord -c /etc/supervisord.conf
fi
Yea off-topic but I still have issues with the new Laravel config:
My app responds significantly slower in the new config
It makes it hard to run scheduler and worker without using multiple processes. I don’t mind paying for multiple VMs but I’ve been running into a loooooot of issues when using multiple processes, so I’m not going to use them until they are more stable