Fix GNOME GUI Login After Upgrade to Debian 10 Buster (VirtualBox VM)
Hello!
Yesterday I upgraded my old Debian VirtualBox VM from Debian 9 stretch to Debian 10 buster.
After going through all the usual upgrade steps from the official documentation and rebooting, I found myself waiting for the GNOME user selection in order to log in. Except that it was stuck with the gray background and nothing except the mouse cursor was showing up or working.
I switched to a text-only terminal (Ctrl+Alt+F5) and logged in via command line. Looking at /var/log/syslog I found the following messages repeating over and over:
gnome-shell[1281]: Failed to set CRTC mode 1448x953: Invalid argument kernel: [ 192.917346] [drm:drm_crtc_helper_set_config [drm_kms_helper]] ERROR failed to set mode on [CRTC:29:crtc-0]
1448x953 is the resolution I am using for the VM.
This current VM was created back when Debian 7 wheezy was still current, and I knew that a more recently created VM (originally with Debian 9 stretch) was working fine after upgrading to 10, so I figured that the info about the resolution from gnome-shell might have something to do with the VM's settings.
Sure enough, I found out that there were about a handful of settings that were different, most likely because over time VirtualBox defaulted to slightly different settings depending on my hardware, the template for the OS I selected (different Debian major releases) and the VirtualBox release itself. A couple of VM starts and configuration changes later I narrowed the problem down to the following VM setting:
Display => Screen => Video Memory
I raised the original 12 MB to 16 MB and thankfully the next boot showed the GNOME login mask as per usual!
Surely this is a very edge case kind of scenario, but I am hoping that this might help you in case you come across the same problem. All the other search results I found regarding roughly the same error message in the logs were about different things.
Thanks for reading!
Memory Leaks / Problems with Long-Running Symfony / Doctrine Console Applications
Hi!
I recently built several console applications that have to keep running as daemons as part of a more complex website. As soon as I added Doctrine for its highly comfortable ORM functionality, I noticed a significant increase in the applications' memory usage, which made sense because it would load Doctrine's code in order to use it. The worst part of it, however, was that the processes kept eating up more and more memory the longer they ran and with each Doctrine query they executed. Finally the processes ended up being killed by Linux's OOM Killer due to the high amount of memory that they wanted allocated for them.
Clearing the Doctrine Entity Manager ($entityManager->clear()) and triggering PHP's garbage collection manually did not help at all. So I assumed it had something to do with the data that Doctrine accumulates in the background.
During my research I finally stumbled upon this Stack Overflow question: Memory leaks Symfony2 Doctrine2 / exceed memory limit
Apparently, Doctrine uses an SQL Logger to log each and every query it uses when running in debug mode.
Due to the nature of Symfony console applications starting up in the dev environment by default when launching them from the command line, it also kept enabling the debug mode. That in turn enabled the SQL Logger which gathered more and more data and kept it in memory.
I decided to launch the processes by simply manually disabling the debug flag. Using the dev environment is not a problem for me, so I just did the following:
$ php app/console custom:command --no-debug
You could also set the environment variable SYMFONY_DEBUG to 0 before launching the command without the --no-debug flag, as it also respects its value - refer to app/console's source code.
Alternatively, you could start it in a non-dev environment:
$ php app/console custom:command --env=prod
or
$ php app/console custom:command -e prod
or just set the environment variable SYMFONY_ENV before launching it.
This way, the SQL Logger is not enabled.
My processes have been running at stable memory usage size ever since.
Another way would be to deactivate the SQL Logger in the code by principle, but that would be defeating the purpose of the nice built-in features of enabling/disabling the debugging mode, so I rather chose the first path. It might come in handy sooner or later after all, and reverting those changes just to re-enable the SQL Logger would be an unnecessary pain.
I hope this was helpful to you. It certainly took me some time to get behind it.