Stuck running up "something bad happened"

Q: Date/Time this occurred (Provide your time zone also)
CET - now

Q: DevKinsta Version

Q: OS Version
MacOS 13.5

Q: Docker Desktop Version

Q: Were any error codes or messages observed? If so, what were they?

Q: Detailed Description of the Problem
**Had multiple issues i could fix to come to the point the Devkinsta was importing the database dump. After that i got a white screen whitin the DevKinsta window on the run up. I was unable to recover from that screen and had to quit it in the activity monitor. Now when running up before the Docker start this “something bad happened” stays within the window, nothing else happening.

Hey @Mikyboy , can you please send me a copy of your main.log file via DM? You can find it by clicking on the question mark icon at the bottom left corner of DevKinsta and then on Reveal log file in File Manager.
We’d like to give a look at it and help you find the culprit.


Thanks, sure

main.log (244.8 KB)

Hi @Mikyboy :wave:

The errors I see thus far doing the Site Pull are:

[2023-08-18 13:12:02.258] [error] [ipcMainStep] Error in operation SITE_PULL, step rsync: Error: Encountered an error in child process 74499: 30. rsync: connection unexpectedly closed (741638 bytes received so far) [generator] rsync error: timeout in data send/receive (code 30) at io.c(231) [generator=3.2.7]


[2023-08-16 19:30:49.922] [error] [ipcMainStep] Error in operation SITE_PULL, step rsync: Error: Encountered an error in child process 57099: 20. rsync error: received SIGUSR1 (code 19) at main.c(1609) [receiver=3.2.7]

I have macOS 13.4.1 and rsync version 2.6.x (rsync --version | head -n1). Because I don’t have your MyKinsta login I cannot reproduce the issue on your specific environment, nor your (exact) macOS version. However, since it is an rsync error I am seeing, it might be worth a shot to try and upgrade rsync if your version is not the server’s version (3.1.3)

To do this you would open either Terminal, or iTerm, and run the following commands:

brew install rsync
brew link --overwrite rsync

Then shut down DevKinsta and Docker Desktop. Start Docker Desktop again and then start DevKinsta, and retry the site pull, and let me know if that works.

In my case it installed rsync 3.2.7 with brew, which exceeds the server’s version of rsync, but as before it was 2.6.x it may make a difference.

If that doesn’t work, send us another logfile and a screenshot of your “System Report” from Spotlight search (or System Settings → General → About), and we’ll continue to review other options

Best regards,

Hi Zach and thanks for that. I was able to update rsynch. Unfortunately now Devkinsta does not start over the “Starting Docker” stage although Docker is started. I have retried many times restarting Docker, restarting both but its stuck there. Find attached my System Report if that is what you meant.

Thanks for some more advice:


Bildschirmfoto 2023-08-25 um 18.29.58
Bildschirmfoto 2023-08-25 um 18.39.38
Bildschirmfoto 2023-08-25 um 18.40.21

Can you provide the output of this command in iTerm/Terminal:

stat /var/run/docker.sock

If that doesn’t exist, can you set these options in Docker Desktop → Settings → Advanced, make sure the CLI is set to System, and the checkboxes below it are checked?

Similar to these instructions:

Thanks, so i had to do the update and then had proplems on Docker. But reinstalled latest Docker version, so now at least DevKinsta runs up again but I am back to the original point where it is says “something bad happened”. This is the output of the command:

Mike@MacBook-Pro-von-User ~ % stat /var/run/docker.sock

stat: /var/run/docker.sock: stat: No such file or directory
Mike@MacBook-Pro-von-User ~ % stat /var/run/docker.sock
stat: /var/run/docker.sock: stat: No such file or directory
Mike@MacBook-Pro-von-User ~ % stat /var/run/docker.sock
16777220 40094491 lrwxr-xr-x 1 root daemon 0 35 “Aug 26 23:34:10 2023” “Aug 26 23:34:10 2023” “Aug 26 23:34:10 2023” “Aug 26 23:34:10 2023” 4096 0 0 /var/run/docker.sock

Hi there :slight_smile:

To clarify are you still getting that latest error (DK0006 Couldn’t download docker images) ?
If that’s the case, maybe try to perform this command line on your terminal (when both DevKinsta and Docker are entirely closed ) :

sudo ln -s "$HOME/.docker/run/docker.sock" /var/run/docker.sock

Once done, please try to open DevKinsta as usual and see if it’s working normally.

Also please rename the previous main.log file to something else (e.g.: main.log.old or something) and try to get the new created main.log file - and send it to us again - in case you’re still getting that “something bad happened” error, so we can check and review from that most recent main.log file.


Hey Agus, no as mentioned docker image download works now, I am over that in the pulling protocoll. But the original tickets problem occured again the ‘something bad happened’:

Thanks for your support

I did run your command btw after renaming the logfile. Still “something bad happened”, find attached the newer main.log file.

main.log (710.2 KB)

Hi @Mikyboy

Can you see if this is what’s currently set in Docker Desktop → Settings → Advanced?

Once that’s set, please fully restart your Mac, and launch Docker Desktop first, then DevKinsta, and it should come up.

I’m on 13.4.1 macOS and 2.11.0 DK

I am not able to replicate the issue exactly, unfortunately.

I did confirm that there are no symlinks in /www/ on the staging space44 environment.

I do see that the database is around 3GB in size, public folder is 2.1G with some old .sql files in it, private folder is 3.2G with old directories in it

wp-config.php looks okay, but you might try removing these lines to test:

define('WP_DEBUG', false);
define('WP_MEMORY_LIMIT', '128M' );

Also, it looks like you have a WordPress drop-in file at public/wp-content/maintenance.php on the staging environment, which is loading a Plesk-powered maintenance page, and also breaking the output of WP-CLI (wp plugin status). Can you try deleting or moving that maintenance.php file out of the way (into private/ perhaps), and try to pull the staging to DevKinsta again?

Hi Angus yes i have done those settings when you mentioned it. I have also restarted. I started Docker now as you said and then DevKinsta, but now even weirder look at the screenshot it request do install Docker???

I will clean out these old files too at some point.

Hey @Mikyboy , the usual solution for this issue is a command you have already run :thinking:. Can you please let us know if rebooting your Mac solves the issue?


Sorry, i rebooted twice. I even uninstlled DevKinsta and reinstalled, but before even logging in it asks me to install Docker despite it even being open.

Thanks for another tip there

Heya Michael!

Looks like you have tried couple of solutions/methods as suggested before (which usually would help to solve the issue) but still not working properly yet. I myself don’t have Mac here (I only use Linux Ubuntu and Windows machine, so couldn’t really try/replicate/test this.

I’ve been thinking now, if you don’t have any important local sites/any data you have stored in Docker, I would suggest to try to uninstall/remove everything (both Docker and DevKinsta) and re-install from scratch - and hopefully that will be working just fine :thinking:
So you may want to try the following steps when removing/uninstalling them:

  1. close and shutdown both DevKinsta and Docker Desktop/engine completely (make sure they are not running in the background).

  2. uninstall/remove DevKinsta on your Mac as shown here.

  3. remove Docker containers, volumes, and networks starting with devkinsta_ , and if you do not need Docker for other applications please uninstall it completely as shown there.

  4. remove the entries added to your hosts file by DevKinsta.

  5. finally remove these two folders on your Mac:
    User/Library/Application Support/DevKinsta (application config)
    User/DevKinsta (site files)

Once done, you may want to re-install the Docker Desktop first, then re-install the DevKinsta. After that please try to open DevKinsta again (if it can detect that Docker is running) and see if it will run properly (to create new WP site, import site from MyKinsta, etc).


Thanks Agus, i will try again. I have done this before but not with those extra commands i guess. Frustrated have to say. Want to hand this over to our dev who is still working ftp but i love Devkinstas idea actually one of the assetts why chosing Kinsta. But like this of course i cant propose to him to also use it. Have to run it successfully myself first. And have to say it never was stable for me so far if you look at all the tickets I already opened.

I ll give you an update.

You’re welcome Michael! :bowing_man:
Sure, please take your time and see if those additional steps would help to solve it :crossed_fingers:
Alright, please let us know again if you have any updates/information/questions.


Agus, this is frustrating. Cant get things to work. I have uninstalled everything and reinstalled. I have reduced the size, but only could delete those one in private, actually deleted the whole folder by accident hope thats not a problem. COuldnt delet the backup.sql as some tool seems to produce this automatically.

But still getting the error “something bad happened”. What to do?

Btw i saw that Docker hung up in the process which took a long time btw like 10-20 Min while the page actually showed fully downloaded 4.57Gb/4.57Gb, not sure if that helps. If i then cancelled the process it brought up another errorDK0072 couldnt delete database file, which i guess is only reasonable then. I had to kill DevKinsta in the Task Manager as i couldnt retry to load the page nore could i cancel. Now starting it up again the page doesnt load i deleted it again from Devkinsta.

Here also the log file.

main.log (702.5 KB)

Hi Michael,

Thank you for your reply and update! Usually by uninstalling and re-installing everything from scratch should work fine.

actually deleted the whole folder by accident hope thats not a problem.

That’s OK, I went ahead and have re-created that “private” folder in your Live site’s root folder (that got deleted by accident previously).

COuldnt delet the backup.sql as some tool seems to produce this automatically.

Indeed that backup.sql file was created (dumped/imported from your existing database on the server side) automatically as the part of the process when importing site from MyKinsta to your local computer (DevKinsta). That backup.sql file on the ~/public folder could be deleted via SSH / SFTP , but when you try to import the site again, that file will be re-created.

I’ve also checked that main.log file you provided (note: I moved it to our internal note/non-public access as it contains sensitive information) and so far noticed the following:

[2023-10-09 17:10:14.915] [info] [ProgressIndicator] { isFailed: false, isOpen: true }
[2023-10-09 17:10:15.122] [info] [ProgressIndicator] { isFailed: false, isOpen: true }
[2023-10-09 17:10:15.487] [info] [terminalExec] Child process exited with code 0
[2023-10-09 17:11:35.933] [info] [containerExec] Command ‘chown -R www-data:www-data /www/kinsta/public/space44’ on devkinsta_fpm finished with exit code 0

from the part of the log above, it looks like the live site’s files have been downloaded completely to your local computer and no issue with it (as you mentioned that it showed fully downloaded 4.57Gb/4.57Gb).

Then the log continued to show the following import database process (from that dumped /public/space44/backup.sql file which has been downloaded to your local container on your computer ),
but somehow the process couldn’t be completed and returned with DK0066 error code, when it was in the process of importing the backup.sql file to your local docker’s container on your computer:

[2023-10-09 17:11:35.938] [info] [importBackupToDb] Import db
[2023-10-09 17:11:35.940] [info] [dockerUtil/getContainer] Get ‘devkinsta_fpm’ Docker container
[2023-10-09 17:25:07.331] [info] [containerExec] Command ‘mysql -h devkinsta_db -u root -p****** SPACE44 < “/www/kinsta/public/space44/backup.sql”’ on devkinsta_fpm finished with exit code 1
[2023-10-09 17:25:07.354] [error] Error - DK0066: IMPORT_DB_DUMP: Error (1): SERROR 2013 (HY000) at line 38387927: Lost connection to MySQL server during query

[2023-10-09 17:25:07.418] [error] [ipcMainStep] Error in operation SITE_CREATION, step rsync: Error - DK0066: IMPORT_DB_DUMP: Error (1): SERROR 2013 (HY000) at line 38387927: Lost connection to MySQL server during query

As far as I could see, there’s no issue with your Live site’s database on our server (and there’s no timed out issue during the DB dump process into that backup.sql file - that’s stored in your ~/public folder), and as we can see above, the DB import process actually failed (DK0066) during the DB Dumped file import process to your local computer (Docker’s container) / not on the server side.

I suspect it might be because of your database is too large (as I noticed via phpMyAdmin tool, your live site’s database size is about ~10 GB), and somehow the import process on your local computer/container then timed out (lost connection to MySQL server during query). And from the above error message, the DB Import lost the connection when it tried to read the line 38387927 (that’s really huge lines, more than 38 million or so).

I also noticed the following large tables (with millions of rows), perhaps when possible if any old data can be deleted/removed to reduce unwanted large DB’s tables/rows as much as possible (may want to consult with your web programmers/developers first to assist you with that database tables’ optimization)

that way, your database size could be reduced significantly and the DB (.sql) then may be able to be imported properly to your local computer’s DB container.

Also, for testing purpose (and to compare the result), can you please also try to import your other site (that’s small in size, i.e: “sebastian” site perhaps that’s around ~1GB) to your local computer with DevKinsta, and see if the site import process could be completed properly without any errors ?
If that other site’s import process could be completed just fine, then most likely the issue here is really something due to the DB size issue as mentioned above (with your “SPACE44” site) which may need to be optimized first.