math-captcha domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/news.numlock.ch/public_html/wp-includes/functions.php on line 6114WordPress database error: [Disk full (/tmp/#sql-temptable-20e-36730-6c3.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")]SHOW FULL COLUMNS FROM `wp_wfLiveTrafficHuman`
WordPress database error: [Disk full (/tmp/#sql-temptable-20e-36730-6c4.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")]SHOW FULL COLUMNS FROM `wp_wfLiveTrafficHuman`
WordPress database error: [Disk full (/tmp/#sql-temptable-20e-36730-6c5.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")]SHOW FULL COLUMNS FROM `wp_options`
Make a diff!
Eliot from the SaltyCrane blog wrote a nice Django management command that allows to easily trace a Django runserver simply by executing ./manage.py trace runserver. Works great!
Django trace tool, django-trace is [..] a Django management command that uses sys.settrace with other Django management commands. https://github.com/saltycrane/django-trace.
via Notes on tracing code execution in Django and Python « SaltyCrane Blog.
Mailman 2.1.11 (or earlier) isn’t compatible to Python 2.6. So if you upgrade your box to Python 2.6 without upgrading to Mailman 2.1.12 at the same time, you’ll run into troubles. And if you’re unlucky (e.g. when running some low-volume mailing lists), you might not even notice it.
One sign of such troubles is that messages sent to your Mailman mailing lists aren’t processed anymore. They simply seem to get “swallowed” by your Mailman server: Messages don’t reach the list, don’t get forwarded to subscribers and there’s no bounce or failure notice. For low-traffic lists, this might go unnoticed for several days or even weeks.
Another sign (that can easily slip through under certain, quite common circumstances) is that as long as you’re running Mailman 2.1.11 with Python 2.6, cron will, every 5 minutes, send an error message to mailman@myhost.com with a subject similar to
Cron <mailman@myhost> /usr/bin/python -S /usr/lib64/mailman/cron/gate_news
and a content like
/usr/lib64/mailman/Mailman/Utils.py:32: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
import sha
Traceback (most recent call last):
File “/usr/lib64/mailman/cron/gate_news”, line 44, in <module>
from Mailman import MailList
File “/usr/lib64/mailman/Mailman/MailList.py”, line 51, in <module>
from Mailman.Archiver import Archiver
File “/usr/lib64/mailman/Mailman/Archiver/__init__.py”, line 17, in <module>
from Archiver import *
File “/usr/lib64/mailman/Mailman/Archiver/Archiver.py”, line 32, in <module>
from Mailman import Mailbox
File “/usr/lib64/mailman/Mailman/Mailbox.py”, line 21, in <module>
import mailbox
File “/usr/lib64/python2.6/mailbox.py”, line 19, in <module>
import email.message
ImportError: No module named message
That by itself wouldn’t be a big problem and probably get noticed quickly if you forwarded mailman@yourhost.com to your admin’s e-mail address. The problem arises if you happen to host a mailing list named “mailman” (which is often set up as a mailing list for testing and debugging). In that (not uncommon) case, all these cron error messages are forwarded to the “mailman” mailing list. This makes about 288 messages per day that are queued in /var/lib/mailman/qfiles/in and won’t be delivered (due to the compatibility problem with Python 2.6).
Once you upgrade to Mailman 2.1.12 (and restart /etc/init.d/mailman), all these messages in /var/lib/mailman/qfiles/in will be queued by your MTA (e.g. postfix). This may seem like a strange loop problem in Mailman (or your MTA configuration), which is quite irritating at first.
Here’s how to solve the problem (you may need to adjust these steps to your settings/system paths):
1) Temporarily stop the Mailman service
/etc/init.d/mailman stop
2) Delete all the queued messages to/for mailman-owner@myhost.mydomain.com in your MTA’s mail queue. For postfix as MTA, the following script may be helpful: mailq by Dan Mick.
3) Delete all the cron-generated error messages in /var/lib/mailman/qfiles/in.
In order to determine these error messages, use Mailman’s show_qfiles command to view the message content, e.g.
/usr/lib64/mailman/bin/show_qfiles /var/lib/mailman/qfiles/in/longnumber.longnumber.pck
The best way to identify these messages is by filtering them according to their file size. Usually they have sizes around 1600 bytes. E.g. for a file size of 1635 bytes, try sth similar to:
cd /var/lib/mailman/qfiles/in
find ./ -size 1635c -exec rm {} \;
4) Once you’ve deleted all these cron error messages in Mailman’s in-queue, you can restart Mailman (/etc/init.d/mailman start). Mailman will then start delivering the remaining valid files in its in-queue. Your MTA/postfix queue looks normal again (i.e. there’s no more overflowing)!
5) Finally, you need to manually “discard all messages marked Defer” for the ‘mailman’ mailing list using the web admin interface (usually on https://myhost.mydomain.com/mailman/admindb/mailman or similar). Before discarding these messages, make sure you don’t discard any valid messages.
That’s it!
Thanks to Mark Sapiro AKA msapiro from #mailman @ irc.freenode.net for very useful hints and help!
P.S. Some other helpful resources in case of Mailman problems:
If you happen to use PyFacebook on Gentoo you probably noticed that djangofb.py didn’t create/copy any skeleton files for the Facebook application to be created (for an example how it should work, take a look at the PyFacebook tutorial).
In order to fix this, just download my update of the pyfacebook-9999.ebuild. This updated ebuild reflects PyFacebook’s move to GIT for versioning (from SVN), hence ensuring that you always use the latest available (‘official’) sources with latest fixes (among others, some changes to /pyfacebook/setup.py to fix the djangofb problem). I also recommend to watch the forks of PyFacebook for recent changes.
If your Python environment seems to be buggy or broken after a recent Python upgrade, it probably is. To fix it, simply execute the following command on your Gentoo box:
# python-updater -v
(note that this process takes quite some time to complete)
Additionally, you might want to make Gentoo check the dependency tree and rebuild broken packages (related to Python or other packages):
# revdep-rebuild
P.S. This is more or less a repost of an earlier post about python-updater.
If you encounter seemingly “strange” Python errors when emerging apps after a Python upgrade, execute:
# python-updater -v
This will rebuild packages that are broken due to the Python upgrade (Note: You can also manually emerge the packages python-updater lists)
If Trac doesn’t run anymore after an ’emerge -uD world’ (i.e. there’s a “500 Internal Server Error”) and Apache complains about “ImportError: No module named trac.web.modpython_frontend”, here’s the solution:
(IOW: Emerge mod_python-3.3.1-r1 from your local portage overlay and restart Apache)