Related

when i enter the option to install openshift origin in fedora 19, system is restarting.. why is it happening??? Question Question
Jenkin installation in a server using unix, using a MAC system Question Question

Question

Site not working after maintenance reboot

Posted March 29, 2018 5.5k views
Fedora

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

Add a comment
zarakoinos
By:
zarakoinos
6 comments
  • zarakoinos March 29, 2018
    Reply Report

    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.

  • zarakoinos March 30, 2018
    Reply Report

    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.

  • jasonjpeters March 30, 2018
    Reply Report

    What is the stack you use to host your site? LEMP? LAMP? and are all of the services running?

  • zarakoinos March 30, 2018
    Reply Report

    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.

  • jasonjpeters March 30, 2018
    Reply Report

    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

  • Show 1 more comments

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.

×
2 answers
ilariap January 29, 2020
Show answer This answer has been marked as resolved by ilariap.
ilariap January 29, 2020

Resolved with these:

  • journal was corrupt -> removed the folder inside /var/log/journal/<hash> [removed error on journal being corrupt: “File /var/log/journal/<hash>/system.journal corrupted or uncleanly shut down, renaming and replacing.”]
  • did an fsck (using the ISO recovery boot) automatically on vda1 but didn’t find anything
  • did a manual fsck on the vda15 (just in case) and it was corrupt too, hinted for deleting the dirty bit, which I did [it was ok afterwards]
  • disabled swap [removed the other boot error “Swap Timed out waiting for device dev-disk-by\x2dlabel-swap.device”]

=> could eventually login normally both via console and with putty.

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help