hp-systray has high CPU usage - Ubuntu Intrepid
Bug #305807 reported by
Daniel Saunders
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HPLIP |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I have an Ubuntu Intrepid server* connected to an HP 3330 MFP printer via USB (though the same thing happened when connected via. the Parallel Port). After some time, the server becomes slow, and looking at the output from 'top' shows that the hp-systray process is taking between 80-100% of CPU power.
I think that this is a repost of this bug - http://
hplip version is 2.8.7-0ubuntu6
* Server is also a mythtv backend/frontend, running XFCE4 as its desktop environment.
To post a comment you must log in.
Hi,
I'm experiencing this problem now with hplip 3.9.2-1 in debian unstable. If I do strace -p
<pid>, I can see:
read(7, "", 236) = 0
select(8, [7], [], [7], {1, 0}) = 1 (in [7], left {0, 999997})
read(7, "", 236) = 0
select(8, [7], [], [7], {1, 0}) = 1 (in [7], left {0, 999997})
read(7, "", 236) = 0
select(8, [7], [], [7], {1, 0}) = 1 (in [7], left {0, 999997})
read(7, "", 236) = 0
select(8, [7], [], [7], {1, 0}) = 1 (in [7], left {0, 999997})
read(7, "", 236) = 0
select(8, [7], [], [7], {1, 0}) = 1 (in [7], left {0, 999997})
read(7, "", 236) = 0
select(8, [7], [], [7], {1, 0}) = 1 (in [7], left {0, 999997})
read(7, "", 236) = 0
...
I used gdb to track it down: posixmodule. c:6101 ceval.c: 3612 ceval.c: 2875 ceval.c: 3708 ceval.c: 2875 ceval.c: 514 hp-systray" , start=257, globals=0xb7f5eacc, locals=0xb7f5eacc, pythonrun. c:1273 eExFlags (fp=0x816e008, hp-systray" , closeit=1, flags=0xbfbb7548) pythonrun. c:879 main.c: 532 python. c:23
(gdb) bt
#0 posix_read (self=0x0, args=0x83a1fcc) at ../Modules/
#1 0x080ced6a in PyEval_EvalFrameEx (f=0x8313ddc, throwflag=0) at
../Python/
#2 0x080d00c5 in PyEval_EvalCodeEx (co=0xb7b7f7b8, globals=0x8381acc,
locals=0x0, args=0x81790b8, argcount=2, kws=0x81790c0, kwcount=0,
defs=0x8383118, defcount=2, closure=0x0)
at ../Python/
#3 0x080ce9fc in PyEval_EvalFrameEx (f=0x8178f7c, throwflag=0) at
../Python/
#4 0x080d00c5 in PyEval_EvalCodeEx (co=0xb7f0ea88, globals=0xb7f5eacc,
locals=0xb7f5eacc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0)
at ../Python/
#5 0x080d02d7 in PyEval_EvalCode (co=0xb7f0ea88, globals=0xb7f5eacc,
locals=0xb7f5eacc) at ../Python/
#6 0x080ed71f in PyRun_FileExFlags (fp=0x816e008, filename=0xbfbb8b8d
"/usr/bin/
closeit=1, flags=0xbfbb7548)
at ../Python/
#7 0x080ed9ea in PyRun_SimpleFil
filename=0xbfbb8b8d "/usr/bin/
at ../Python/
#8 0x08059357 in Py_Main (argc=1, argv=0xbfbb7614) at ../Modules/
#9 0x08058722 in main (argc=0, argv=0xb7c75ec8) at ../Modules/
The problematic place in python source is here: hplip/hpdio. py (94): run
(gdb) pyframe
/usr/share/
Since the read() reads a pipe and returns 0, probably the other end of
pipe was closed. The pipe is created at systray.py:122 and is used to
communicate with something called hpssd (see lines 134 and 141). So I
guess there is some problem with the hpssd, which is not correctly
handled in hpdio.py.
Regards
Michal Sojka