This issue was occurring because my kernel was refusing to upgrade, because I was on a VPS. (you need to get your VPS provider to upgrade it for you)
Run uname -r, if it returns something like this: "2.6.32-042stab084.20" That's probably the reason why docker isn't starting. Your kernel isn't compatible.
If you're not on a VPS and can upgrade your kernel, try instructions on this page: http://docs.docker.io.s3-website-us-west-2.amazonaws.com/installation/ubuntulinux/
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-3.8.0-34-generic.postrm line 328.
dpkg: error processing linux-image-3.8.0-34-generic (--remove):
subprocess installed post-removal script returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)
You might not be able to upgrade the kernel on your VPS. Contact your VPS provider and get them to upgrade the kernel for you.
- Find out the owner of your apache process (usually www-data).
- Look at the top of the "Automation Settings" page in your WHMCS admin area. It should say something like: php -q /var/www/whmcs/admin/cron.php (keep this handy for step 4)
- In terminal run: crontab -e -u www-data
- Ensure you have a line that says:
0 6 * * * php -q /var/www/whmcs/admin/cron.php (note: this should be the same file path you got for your own install in step 2)
This seems to only be an issue with CherryPy 3.3.0, I switched back to CherryPy 3.2.3 and it worked again.
I noted it on their bitbucket issue here: https://bitbucket.org/cherrypy/cherrypy/issue/1298/ssl-not-working
ChannelFailures: VerificationError("importing 'C:\\\\Python27\\\\lib\\\\site-packages\\\\cryptography\\\\_Cryptography_c
ffi_48bbf0ebx93c91939.pyd': DLL load failed: %1 is not a valid Win32 application.",)
These error messages are solved with this install: http://slproweb.com/download/Win32OpenSSL-1_0_1g.exe
If you have a 32-bit version of python, that install will move the correct DLLs to your system32 folder.
I purchased a chinese access controller and reverse engineered some functionality of the windows software that came with it. I made a python library that does some of the same functions as the desktop software: https://github.com/pawl/
I use this library to tie our access controller into with our billing system (called WHMCS) and another web application (which is meant to be a self-documenting way to activate/deactivate RFID badges): https://github.com/
Now, whenever someone stops paying for 5+ days, their RFID badge is deactivated because a "hook" in WHMCS sends a request to a webservice that uses the access control library.
At one point, it got so bad that the application would not even start anymore.
- Get Root Explorer
- Navigate to your system folder and open "build.prop" in the text editor
- Edit "dalvik.vm.heapsize" and "dalvik.vm.heapgrowthlimit" to the following:
- Restart your phone, open the bitcoin application, and backup your keys before it crashes again.
This example looks particularly awesome: http://visjs.org/examples/graph/17_network_info.html
After trying a bunch of different solutions in the code, I ended up having to restart MySQL to get this error message to go away.
In this instance, we were getting hit with web crawlers according to the access log and the syslog was saying this: /usr/sbin/apach invoked oom-killer
This issue occurs when apache opens up too many child processes, uses up too much memory, then OOM killer starts shutting down random processes like mysql.
The problem ended up being that our apache2.conf did not have any configuration limiting the number of processes that Apache could open. It might have had a default, but the default was too high. We were using Apache ITK MPM and the apache2.conf only mentioned prefork, worker, and event MPMs. You can check which MPM you are running with "apache2 -V".
Adding this to the configuration solved the problem:
At first I had the ServerLimit and MaxClients set to 150 and it seemed like apache was ignoring ServerLimit and Maxclients. However, ITK MPM creates an extra fork for each request (according to their site), that's why there was 200+ processes running for my limit of 150. So, the process count is going to be 2x the limit you set.