Question
Question
Site not working after maintenance reboot
DO announced maintenance reboots to all servers affecting FRA1 which i’m hosted because of spectre and meltdown vulnerabilities.
After this action, my website is down and cannot access it via ftp or ssh or ping it’s ip address.
However, I can access my droplet and seems to be up.
I can also access the console where it says “Give root password for maintenance (or press Ctrl-D to continue)”
When i give my root password i am able to log in to my system but still don’t know what to do to bring my website back.
Thank you in advance
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
×
I also opened a support ticket replying to the email sent, but after hours still no answer.
Site is production and should fix this issue ASAP.
Thanks.
Also tried via console to start httpd, mysqld and other services, it falls back to “Give root password for maintenance (or press Ctrl-D to continue)”.
journalctl - xb keeps playing messages of failed ftp mounts every 3 hours aproximately. So something is really going wrong after DO maintenance reboot.
What is the stack you use to host your site? LEMP? LAMP? and are all of the services running?
I’m Using LAMP. As i said before the only access i have is by droplet’s console and tried to start httpd and other services.
What exactly happens:
Logging in by droplet’s console and then checking, systemctl is-active httpd.service or mysqld.service –> inactive.
When i’m trying to bring them up (i.e systemctl start httpd.service), for some reason it kicks me out without executing the command and have to log in again just to see that all services are still inactive.
PS. I use a Fedora 21 system.
hmmm that is quite odd. I do not use Fed21 or like systems all to much. I would work on regaining normal SSH access while in the console then work on it that way. Something to try and do is to boot the droplet using the recovery kernal and work from there.
https://www.digitalocean.com/community/tutorials/recovering-files-from-a-compromised-droplet-using-the-recovery-iso
Thank you Jason. I want to ask a question. When i login from droplet’s console, it informs me that i am on “emergency mode”. Is this normal? Does this happen to your console?
I’m asking because i guess that this is the reason why i can’t start sshd daemon…
I also thought of enabling it (systemctl enable sshd.service) and then reboot the droplet.
Nothing changed; Daemon is inactive mode again and same happens to all services too (httpd, mysqld, vsftpd, iptables etc).