USB printer message fills up logs

Bug #225898 reported by Michael on 2008-05-02
This bug affects 2 people
Affects Status Importance Assigned to Milestone
hplip (Ubuntu)

Bug Description

/var/log/syslog and /var/log/user.log are filled up with the following messages:

May 2 12:04:45 DELL HP_LaserJet_1200?serial=00CNBF183081: io/hpmud/musb.c 1339: unable to write data hp:/usb/HP_LaserJet_1200?serial=00CNBF183081: No data available
May 2 12:04:45 DELL HP_LaserJet_1200?serial=00CNBF183081: io/hpmud/musb.c 976: bulk_write failed buf=0xbff159cc size=8064 len=-19: No data available

I tried to print two pages and feeded the paper manually to the printer. The effect was, that i got a message a la 'printer has no paper' and that this message does not disapear even if the print job succeeded and if i fed in new paper.

Ubuntu Release: 8.04 with latest updates
hplip: 2.8.2-0ubuntu8
cupsys: 1.3.7-1ubuntu3

grep -c HP_LaserJet_1200?serial user.log
wc -l user.log
7969984 user.log
ls -l /var/log/syslog /var/log/user.log
-rw-r----- 1 syslog adm 1267548604 2008-05-02 22:17 /var/log/syslog
-rw-r----- 1 syslog adm 1267222950 2008-05-02 22:13 /var/log/user.log

Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at . I have classified this bug as a bug in cupsys.

I have a similar problem with a HP Photosmart 2570.
Printing gave no errors but after a while I was unable to log into the account because /var/log had filled the the partition
to 100%

After investigation it turns out that various logs, deamon.log, syslog etc were filled with these three lines:

Jan 30 15:54:39 jurek-desktop hp[2767]: io /hpmud/musb.c 725: invalid device wIndex=1, retrying wIndex=100: Device or resource busy
Jan 30 15:54:39 jurek-desktop hp[2767]: io /hpmud/musb.c 1389: unable to write data hp:/usb/Photosmart_2570_series?serial=MY6CJ311FZ04DY: Device op resource busy
Jan 30 15:54:39 jurek-desktop hp[2767]: io /hpmud/musb.c 1022: bulk write failed buf=0xbfc48764 size=7680 len=16: Device or resource busy

These lines are written in a few minutes, 4.5 GB in total !

Till Kamppeter (till-kamppeter) wrote :

Problem is excessive logging by the HPLIP software (probably the CUPS backend) in an error case. Forwarding upstream.

To the HP developers, some part of HPLIP, probably the printer I/O part which is used by the "hp" CUPS backend seems to try to access the printer several thousand times per second and on each failure a log message is produced (perhaps one per byte to be sent). This excess of log messages quickly fills up any size of hard disk. If a problem occurs repeatedly, one could perhaps issue one log message and tell how many times the problem repeated. One could also give up or wait some seconds if a certain piece of data sent leads to an error instead of trying to resend it several thousad times per second.

Lameventanas (lameventanas) wrote :

This is probably related to this bug I filed a while ago:

Its a very simple fix, I submitted a patch already.

Josh Kelley (joshkel) wrote :

As far as I can tell, this is NOT a duplicate of #816763.

That bug states that CommonDefinitions.h uses the wrong log facility for messages created by the dbglog macro in prnt/hpcups/*.cpp.

The error messages in this bug are created by the BUG macro in io/hpmud/musb.c. One error message is created by the
BUG("bulk_write failed buf=%p size=%d len=%d: %m\n") call in the musb_write function, and the other error message is created by the BUG("unable to write data %s: %m\n") call in the musb_raw_channel_write function.

From what I can tell from looking at the code, the only way that musb_raw_channel_write will log its error message is if musb_write had just failed and logged its error message, so I believe that the simplest fix is to remove that BUG call from musb_raw_channel_write and let syslog use its "last message repeated N times" handling to prevent musb_write's BUG call from filling up the disk.

I've run into this problem in a Debian 5 installation running a backported hplip 3.9.10, but as far as I can tell, Ubuntu's version of hplip and the latest upstream hplip have the same problem.

Josh Kelley (joshkel) wrote :

This bug may be a variation of

Changed in hplip:
status: New → Confirmed
Changed in hplip (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers