Brutally removing mySQL crashes ActiveStorage in magical ways #40091
I was installing Ghost, a blogging system which requires mySQL, but I decided to give up. Because I'm using postgresql for my Rails application, put on a VPS mantained with @excid3's wonderful HatchBox service (which has nothing to do with this problem and it's all my mistake), I decided to clean up all the mySQL-related things I had to put on my server to install Ghost. I used apt-get remove mysql* and various then I had the really bad idea to put in this command to delete and cleanup all the mysql related things because I thought I didn't need them:
which is suggested in this pretty authoritative (it's from Cloud66, even if it's an unrelated product, I found it looking how to completely remove mySQL).
I had to redeploy all my applications one at time because ActiveStorage exploded, some time after this command (not immediatly) and all my applications gave me this error, at the execution with the webserver, at the
So, while now I understood the big mistake I made and that somewhat some mySQL named files are needed by ActiveStorage, I think that this thing should be documented more accessibly somewhere (saying that removing mySQL named files is a bad idea if you have a rails app) with instructions on how to fix (or just "rebuild everything") and maybe fixed (making mySQL named files not mandatory?). I found some other guy on StackOverflow who had my same error, after "fixing a problem with mySQL", maybe it should
Anyway, I will never remove some random configuration files anymore, I learnt the lesson. It was all my mistake! But we can help other users like me stopping
Rails version: Rails 5.2.3
Ruby version: ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]
Ubuntu version: Ubuntu 20.04.1 LTS
The text was updated successfully, but these errors were encountered:
The issue you described feels like some DB configuration mis-happening that just happens to cause another library(here rails) to misbehave. It could have caused any framework to misbehave .
I didn't actually get what you meant by that. ActiveStorage have no such requirement. If MySQL is causing issues, every DB related functions will cause issues.
#config/application.rb require "active_storage/engine"
Rails is not coupled with MySQL. A mis-configured MySQL (or any DB) setup will cause issues with anything, not just rails
They are not.
I like the thought and there are many ways to do that but this issue tracker is not the right place of these kinds of issues.
So why @KapilSachdev all my rails app that worked for months suddenly stopped after I executed that command into my tewrminal? I don't use mySQL, I just wanted to uninstall it, but after I did that my apps stopped working giving that activestorage error, and I don't even use activestorage in all of them. After months of working!
I don't know the impact of the command mentioned.
But the issue you are encountering looks like loading problem with
If you don't want to use active_storage (or any component) in some app, you can choose to require components individually.
# config/application.rb # Pick the frameworks you want: require 'active_model/railtie' require 'active_job/railtie' require 'active_record/railtie' require 'active_storage/engine' require 'action_controller/railtie' require 'action_mailer/railtie' # require 'action_mailbox/engine' # require 'action_text/engine' require 'action_view/railtie' # require 'action_cable/engine' # require "sprockets/railtie" require 'rails/test_unit/railtie'
Take care while doing this, as you have to remove configuration introduced by components as well.
You may want to check whats in line
Maybe there is more to your issue or not, but rails does not uses MySQL in the way described in the issue description.
Ok and nothing have been changed with MySQL, its not reinstalled, whatever that command did, you never tried to recover that?
So this is what I understood, a command was ran to uninstall MySQL, it broke the rails app, then rails apps were configured again and they started working.
So if rails has to do anything with what you have described, it would still haven't been working as the MySQL state is as is in the machine.
I don't use mySQL. I use PostgreSQL for my rails apps.
I just installed it for Ghost, I uninstalled it normally, I reinstalled it again for Ghost and then I uninstalled it again because I don't need it and gave this command found online to clean up anything it left behind.
This doesn't simply uninstall mySQL, this delete all files that contain the world mysql in them as far as I know.
After I gave that command, deleting all files with mysql in name, all my rails app that have been working for months suddenly stopped working.
I reinstalled them and they began to work again so reasonably the problem was deleting all files contaning mySQL in the name.
It's easy to try reproducing this. One of my applications? See ferdi2005/asdbot. I didn't change its code. I just gave that command, it stopped working (also executing rails c didn't work) and I deleted its files and then reinstalled it, it returned working just fine as it did for months before I gave that command. I did it for all my applications and now they're working.
I didn't executed this command the first time I uninstalled mySQL (and my rails app didn't have problems that time), I executed it only the second time and I got these problems.
I checked the impact of the command and what it does is find all the files containing
And doing so deletes the
Thanks for the issue, and for the discussion so far.
While it seems reasonable that Rails should continue working if you uninstall mysql when you aren't using mysql, the command you provided does more than uninstall mysql. As you mentioned, it will remove any file that contains "mysql".
As an example of where this might cause problems, that command would remove
I don't think we should expect Rails continue working if files from within Rails have been removed. Given that, I am going to close this for now.
If I am missing something and you would like me to reopen the issue, then I agree we would need a clear way to reproduce this. While in theory it is easy to reproduce by running the command you provided, I don't plan on running that on my local machine because it would break a lot of things. Do I need to deploy something first, or run in a container? If so, then reproduction steps might include a script to set all that up, or at least detailed instructions for what I should do. Without that, this issue is a bit to broad for me to be as helpful as I would like to be. There are a whole lot of things that might have gone wrong. Some of them might be something fixable inside Rails, but others (like removing files from within the framework) don't make sense to fix.