CUPS printer hangs after inactivity, requires CUPS restart

Discussion in 'Linux Networking' started by Frnak McKenney, Jul 29, 2005.

  1. My Ethernet-attached Brother MFC-420N All-in-one printer hangs on
    the first print job after a period of inactivity. The printer does
    get some data from CUPS (its LCD panel reports "Receiving Data") but
    the job never (as in hours/overnight) finishes.

    I can clear the problem temporarily by restarting the CUPS daemon
    and pressing the Stop/Exit button on the MFC-420N. Once the queue
    is un-jammed this way, the entire queue prints normally (barring
    out-of-ink and out-of-paper conditions). However, if I let the
    printer sit idle for a while (ten minutes? an hour?), the next
    print job will again get partway through and stop.

    I'm finishing up on a project that has kept me fairly busy for the
    past three months, so I won't be at a point to do any extensive
    testing on the problem for a few weeks, but I thought I'd ask if
    anyone has seen anything like this before. I mean, there's always
    the _chance_ that it's something simple, stupid, and obvious on
    _my_ part, right? <grin>

    The system doesn't crash, I don't need to reboot or switch to
    single-user mode to clear the problem, and what does come out
    appears to be good quality. The Print function sucks ink like a
    camel drinks water when it hits an oasis, but that's most likely
    a hardware problem. <grin>

    It is, however, an annoyance. The CUPS server and the printer are
    down the hall, so every time I want to print I have to queue the
    job, then walk down an manually get the printer going. If there is
    a simple way of finding out why it's behaving this way -- and
    hopefully fixing it -- I'd like to give it a shot.

    Linux version: SuSE 9.1
    Linux manticore 2.6.4-52-default #1
    Wed Apr 7 02:08:30 UTC 2004
    i686 i686 i386 GNU/Linux
    CUPS version: cups-1.1.20-103
    CUPS driver: cupswrapperMFC420CN-1.0.0-1
    Samba version: Version 3.0.8-1.1.1-SUSE

    Network:
    office 192.168.0.1
    manticore 192.168.0.2 # CUPS, SAMBA servers
    ma-win2k 192.168.0.4
    ma-win2k-dev 192.168.0.5
    brn_60fb75 192.168.0.99 # The Brother MFC-420N
    # All-in-one Printer/etc.

    Generally I'm printing from 'office' via a Samba-defined network
    printer that feeds into CUPS. Some additional information on the
    symptoms when this problem occurs:

    1) Nothing prints, not even an initial page.

    2) If the document is "large"(*) it simply sits in the CUPS print queue
    for the MFC-420N until I notice it and restart CUPS and the
    printer. Once I do this, the job does not vanish but prints
    as I would expect it to.

    I have never seen it spontaneously begin/resume printing
    although on several occasions the situation has persisted
    overnight.

    3) If this document is "short"(*) it vanishes from the CUPS queue.

    4) If the MFC-420N CUPS queue is Stopped and a "short" document queued,
    it doesn't vanish and I can restart CUPS, then release the queue
    and the document will print. Usually.

    (*) A text-only document of a couple of pages, for example, may vanish,
    while a one-page 'web page printout won't.

    Once this problem occurs, the only way to get things going that I have
    discovered is to do the following:

    - Restart CUPS: /etc/init.d/cups restart, and then
    - Press the Stop/Exit button on the printer.

    Once I've done this, CUPS thinks for a bit (5-10 seconds), then the
    printer makes printing noises and eventually document pages roll out.

    Once things are moving they seem to keep moving as long as there are
    documents in the queue. The printer can pause (paper out) for an
    hour, then pick up again without the queue becoming jammed once more
    paper is loaded. Until the queue empties and the MFC-420N sits idle
    for a bit. Then the whole "restart CUPS, restart MFC-420N" process
    has to be repeated.

    Any clues, pointers, or suggestions will be appreciated, but please
    don't invest large amounts of your time at this point since I may
    not be able to immediately implement them. I will, however, post
    back my results and any fix or better workaround I find (or have
    pointed out to me <grin>).

    Thanks...


    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)
     
    Frnak McKenney, Jul 29, 2005
    #1
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.