FAQ
Hi there,

When I try to login to the admin interface for one specific mailing list
on my site (the others work ok) I get this:

----------
Bug in Mailman version 2.1.5

We're sorry, we hit a bug!

Please inform the webmaster for this site of this problem. Printing of
traceback and other system information has been explicitly inhibited,
but the webmaster can find this information in the Mailman error logs.
----------


However when I check the error log on my server (it's
/var/log/mailman/error) there is nothing.

Any help or guidance would be greatly appreciated. Thanks!

-Brian

Search Discussions

  • Mark Sapiro at Jul 14, 2006 at 2:25 am

    Brian Cohen wrote:
    When I try to login to the admin interface for one specific mailing list
    on my site (the others work ok) I get this:

    ----------
    Bug in Mailman version 2.1.5

    We're sorry, we hit a bug!

    Please inform the webmaster for this site of this problem. Printing of
    traceback and other system information has been explicitly inhibited,
    but the webmaster can find this information in the Mailman error logs.
    ----------


    However when I check the error log on my server (it's
    /var/log/mailman/error) there is nothing.

    Are you sure that's where Mailman's logs are? Check the setting of
    LOG_DIR in mm_cfg.py. If there isn't one, the logs are probably in the
    logs/ directory in the same mailman directory as lists/, data/,
    archives/, etc.


    That said, does anything work for this list? Can you get its listinfo
    page or its admindb page? Does it process mail, requests, etc.? If the
    answer to all of these is no, the lists/listname/config.pck file is
    probably corrupt. The first try is do move it aside, e.g. rename it
    config.pck.bad, and thus let Mailman try the config.pck.last which may
    be OK.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brian Cohen at Jul 14, 2006 at 5:21 am

    Mark Sapiro wrote:
    Brian Cohen wrote:
    When I try to login to the admin interface for one specific mailing list
    on my site (the others work ok) I get this:

    ----------
    Bug in Mailman version 2.1.5

    We're sorry, we hit a bug!

    Please inform the webmaster for this site of this problem. Printing of
    traceback and other system information has been explicitly inhibited,
    but the webmaster can find this information in the Mailman error logs.
    ----------


    However when I check the error log on my server (it's
    /var/log/mailman/error) there is nothing.

    Are you sure that's where Mailman's logs are? Check the setting of
    LOG_DIR in mm_cfg.py. If there isn't one, the logs are probably in the
    logs/ directory in the same mailman directory as lists/, data/,
    archives/, etc.
    On my distro, the logs/ directory is symlinked to /var/log/mailman. It's
    definitely the right dir, there's other stuff being logged in the files
    there.

    That said, does anything work for this list? Can you get its listinfo
    page or its admindb page? Does it process mail, requests, etc.? If the
    answer to all of these is no, the lists/listname/config.pck file is
    probably corrupt. The first try is do move it aside, e.g. rename it
    config.pck.bad, and thus let Mailman try the config.pck.last which may
    be OK.
    Everything else works: listinfo, admindb, mail processing and requests.
    Just admin triggers a bug.

    -Brian
  • Mark Sapiro at Jul 14, 2006 at 2:47 pm

    Brian Cohen wrote:
    Everything else works: listinfo, admindb, mail processing and requests.
    Just admin triggers a bug.

    And only for one list? And there's nothing in the 'error' log? This is
    strange.

    Edit the file mailman/scripts/driver. About 30 lines into the file you
    will see

    STEALTH_MODE = 1

    change this to

    STEALTH_MODE = 0

    You don't have to restart Mailman. That's only required after changes
    affecting the queue runners, not the web interface.

    After making this change, the error information should display on the
    web page. Please report this information, and we can help further.

    Once you get the error information and traceback, you can set
    STEALTH_MODE back to 1 if you don't want this info displayed in
    general.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brian Cohen at Jul 14, 2006 at 2:48 pm
    Ok, cool. Here's the traceback:

    Traceback:

    Traceback (most recent call last):
    File "/var/lib/mailman/scripts/driver", line 250, in ?
    run_main()
    File "/var/lib/mailman/scripts/driver", line 120, in run_main
    print_traceback(logger)
    File "/var/lib/mailman/scripts/driver", line 147, in print_traceback
    traceback.print_exc(file=logfp)
    File "/usr/lib/python2.3/traceback.py", line 210, in print_exc
    print_exception(etype, value, tb, limit, file)
    File "/usr/lib/python2.3/traceback.py", line 123, in print_exception
    print_tb(tb, limit, file)
    File "/usr/lib/python2.3/traceback.py", line 68, in print_tb
    line = linecache.getline(filename, lineno)
    File "/usr/lib/python2.3/linecache.py", line 14, in getline
    lines = getlines(filename)
    File "/usr/lib/python2.3/linecache.py", line 40, in getlines
    return updatecache(filename)
    File "/usr/lib/python2.3/linecache.py", line 93, in updatecache
    lines = fp.readlines()
    MemoryError


    Thanks,

    -Brian

    Mark Sapiro wrote:
    Brian Cohen wrote:
    Everything else works: listinfo, admindb, mail processing and requests.
    Just admin triggers a bug.

    And only for one list? And there's nothing in the 'error' log? This is
    strange.

    Edit the file mailman/scripts/driver. About 30 lines into the file you
    will see

    STEALTH_MODE = 1

    change this to

    STEALTH_MODE = 0

    You don't have to restart Mailman. That's only required after changes
    affecting the queue runners, not the web interface.

    After making this change, the error information should display on the
    web page. Please report this information, and we can help further.

    Once you get the error information and traceback, you can set
    STEALTH_MODE back to 1 if you don't want this info displayed in
    general.
  • Mark Sapiro at Jul 14, 2006 at 3:54 pm

    Brian Cohen wrote:
    Ok, cool. Here's the traceback:

    Traceback:

    This should be the traceback of the original error, but the attempt to
    produce it produced the MemoryError exception which produced the
    second traceback below. This is why the original traceback is not in
    the 'error' log.

    Traceback (most recent call last):
    File "/var/lib/mailman/scripts/driver", line 250, in ?
    run_main()
    File "/var/lib/mailman/scripts/driver", line 120, in run_main
    print_traceback(logger)
    File "/var/lib/mailman/scripts/driver", line 147, in print_traceback
    traceback.print_exc(file=logfp)
    File "/usr/lib/python2.3/traceback.py", line 210, in print_exc
    print_exception(etype, value, tb, limit, file)
    File "/usr/lib/python2.3/traceback.py", line 123, in print_exception
    print_tb(tb, limit, file)
    File "/usr/lib/python2.3/traceback.py", line 68, in print_tb
    line = linecache.getline(filename, lineno)
    File "/usr/lib/python2.3/linecache.py", line 14, in getline
    lines = getlines(filename)
    File "/usr/lib/python2.3/linecache.py", line 40, in getlines
    return updatecache(filename)
    File "/usr/lib/python2.3/linecache.py", line 93, in updatecache
    lines = fp.readlines()
    MemoryError

    So what we know is we encounter a MemoryError in trying to print the
    original traceback, so my guess is that was probably also due to a
    MemoryError.

    Does the list that fails have a large number of members compared to the
    other lists?

    MemoryError means the underlying Python interpreter got a denial on an
    attempt to allocate more memory (C's malloc() function). Is your web
    server enforcing some memory limit on CGI processes?

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brian Cohen at Jul 14, 2006 at 3:55 pm

    Mark Sapiro wrote:
    Brian Cohen wrote:
    Ok, cool. Here's the traceback:

    Traceback:

    This should be the traceback of the original error, but the attempt to
    produce it produced the MemoryError exception which produced the
    second traceback below. This is why the original traceback is not in
    the 'error' log.

    Traceback (most recent call last):
    File "/var/lib/mailman/scripts/driver", line 250, in ?
    run_main()
    File "/var/lib/mailman/scripts/driver", line 120, in run_main
    print_traceback(logger)
    File "/var/lib/mailman/scripts/driver", line 147, in print_traceback
    traceback.print_exc(file=logfp)
    File "/usr/lib/python2.3/traceback.py", line 210, in print_exc
    print_exception(etype, value, tb, limit, file)
    File "/usr/lib/python2.3/traceback.py", line 123, in print_exception
    print_tb(tb, limit, file)
    File "/usr/lib/python2.3/traceback.py", line 68, in print_tb
    line = linecache.getline(filename, lineno)
    File "/usr/lib/python2.3/linecache.py", line 14, in getline
    lines = getlines(filename)
    File "/usr/lib/python2.3/linecache.py", line 40, in getlines
    return updatecache(filename)
    File "/usr/lib/python2.3/linecache.py", line 93, in updatecache
    lines = fp.readlines()
    MemoryError

    So what we know is we encounter a MemoryError in trying to print the
    original traceback, so my guess is that was probably also due to a
    MemoryError.

    Does the list that fails have a large number of members compared to the
    other lists?
    Just two members on this list.
    MemoryError means the underlying Python interpreter got a denial on an
    attempt to allocate more memory (C's malloc() function). Is your web
    server enforcing some memory limit on CGI processes?
    Not that I know of...

    Thanks!

    -Brian
  • Mark Sapiro at Jul 14, 2006 at 4:06 pm

    Brian Cohen wrote:
    Mark Sapiro wrote:
    Does the list that fails have a large number of members compared to the
    other lists?
    Just two members on this list.

    I am puzzled. Is the size of the lists/<listname>/config.pck file for
    this list as small as or smaller than the others for lists that work?

    If you want to send me off list the config.pck file, I'll see what I
    can figure out, but first what does 'ls -l lists/<listname>/' show?

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brian Cohen at Jul 14, 2006 at 4:16 pm

    Mark Sapiro wrote:
    Brian Cohen wrote:
    Mark Sapiro wrote:
    Does the list that fails have a large number of members compared to the
    other lists?
    Just two members on this list.

    I am puzzled. Is the size of the lists/<listname>/config.pck file for
    this list as small as or smaller than the others for lists that work?
    Yes it's a few bytes smaller than a working list that has about 9 members.
    If you want to send me off list the config.pck file, I'll see what I
    can figure out, but first what does 'ls -l lists/<listname>/' show?
    drwxrwsr-x 2 root list 4096 Jul 14 12:00 .
    drwxrwsr-x 8 root list 4096 Jan 20 11:44 ..
    -rw-rw---- 1 root list 3324 Feb 19 2005 config.db
    -rw-rw---- 1 root list 3324 Feb 19 2005 config.db.last
    -rw-rw---- 1 list list 4280 Jul 14 12:00 config.pck
    -rw-rw---- 1 list list 4280 Jul 14 11:28 config.pck.last
    -rw-r--r-- 1 root list 189 Feb 19 2005 handle_opts.html
    -rw-rw---- 1 list list 133 Jul 7 04:08 pending.pck
    -rw-rw-r-- 1 apache list 24 Jul 14 01:23 request.pck


    Thanks,

    -Brian
  • Mark Sapiro at Jul 14, 2006 at 4:35 pm

    Brian Cohen wrote:
    Mark Sapiro wrote:
    If you want to send me off list the config.pck file, I'll see what I
    can figure out, but first what does 'ls -l lists/<listname>/' show?
    drwxrwsr-x 2 root list 4096 Jul 14 12:00 .
    drwxrwsr-x 8 root list 4096 Jan 20 11:44 ..
    -rw-rw---- 1 root list 3324 Feb 19 2005 config.db
    -rw-rw---- 1 root list 3324 Feb 19 2005 config.db.last
    -rw-rw---- 1 list list 4280 Jul 14 12:00 config.pck
    -rw-rw---- 1 list list 4280 Jul 14 11:28 config.pck.last
    -rw-r--r-- 1 root list 189 Feb 19 2005 handle_opts.html
    -rw-rw---- 1 list list 133 Jul 7 04:08 pending.pck
    -rw-rw-r-- 1 apache list 24 Jul 14 01:23 request.pck

    The files config.db and config.db.last are left over from an old
    Mailman 2.0.x. When you upgraded to 2.1.x these were converted to the
    corresponding config.pck files. I'm sure it has nothing to do with
    your problem, but it is a good idea to remove the config.db files
    because there is a remote possibility that both config.pck files could
    become unusable and Mailman would automatically revert to the outdated
    config.db and reconvert it.

    If you want to send me the config.pck off list, I'll look at it and see
    what I can find.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJul 13, '06 at 9:50p
activeJul 14, '06 at 4:35p
posts10
users2
websitelist.org

2 users in discussion

Mark Sapiro: 5 posts Brian Cohen: 5 posts

People

Translate

site design / logo © 2022 Grokbase