--- On Tue, 7/27/10, John W. Baxter <jwblist3@???> wrote:
> It is possible that the problem was triggered by doing an
> initial test using
> the command line shown above, as root. That could have
> created a file only
> root can read or write. Or it could be something else
> entirely, of course.
>
> Python tracebacks, for one with Python knowledge, can be
> very useful. It's
> annoying when they get truncated (Exim does that when we
> pipe to a Python
> program which fails (every few days, for reasons we haven't
> figured
> out--retries do not fail--it's always a message from a
> mobile device on
> AT&T, which should narrow it down)). A switch to get
> more than one line
> logged would be nice--I hope I haven't missed such a thing
> now that I've
> ranted.
I crossed my fingers (I had visions of megabytes of stuff being dumped on the console) and put the -D switch in the spamd startup options and restarted spamd.
It actually dumped only about a dozen lines on the console, having to do with startup. After that, all the debugging trace info was logged to SA's log, which I have configured as /var/log/exim/spamd.log. spamd.log quickly ran to a megabyte. With enough data to chew on, I yanked out the -D option and restarted SA again.
The pyzor-relevant debug output in spamd.log (time stamps removed):
dbg: pyzor: pyzor is available: /usr/bin/pyzor
dbg: dns: entering helper-app run mode
dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin10626hxECI3tmp
dbg: util: setuid: ruid=8 euid=8
dbg: pyzor: got response: Traceback (most recent call last):\n File "/usr/bin/pyzor", line 4, in ?\n pyzor.client.run()\n File "/usr/lib/python2.4/site-packages/pyzor/client.py", line 991, in run\n ExecCall().run()\n File "/usr/lib/python2.4/site-packages/pyzor/client.py", line 176, in run\n os.mkdir(homedir)\nOSError: [Errno 13] Permission denied: '/var/spool/exim/scan/.pyzor'
dbg: dns: leaving helper-app run mode
warn: pyzor: check failed: internal error, python traceback seen in response
Looking at client.py , line 175-176 I see:
if not os.path.exists(homedir):
os.mkdir(homedir)
/var/spool/exim/scan/.pyzor definitely exists, so says I, why the heck is it trying to make a dir that already exists? (I don't know Python but the meaning seemed clear)
After studying it for 5 minutes, I Googled "os.path.exists", which got me to the answer at:
http://docs.python.org/library/os.path.html
It seems the os.path.exists function returns false if permission is denied to os.stat(path), which as one might surmise is simply linux stat.
IOW, a permission problem as suspected.
The following line revealed the problem:
dbg: util: setuid: ruid=8 euid=8
On my machine, uid 8 is user mail. I had configured spamd to run as user mail, so that made sense. However, the pyzor home folder was owned by user exim. I had thought it was sufficient to put the homedir in group mail and make the dir group writable. I didn't count on a python existence test that requires 'stat' privilege.
Solution:
=================================
I changed the SA options to run as exim. This caused a new permissions problem (for exim) on the spamd socket. spamd creates this socket as root. With a few more tweaks, I now have pyzor running without the traceback error message.
However, the pyzor result is frequently:
check failed: no response
So, traceback problem solved. However, Pyzor doesn't seem to contribute much to spam detection, and adds networking delay which may not even elicit a response. So, I will probably kill it and be done with it. I have some other exim issues of higher priority.
