HP-setup (python2) huge CPU load Topic is solved

[viking60]

I just realized that one of my boxes has a constantly high CPU load. I checked with inxi like this:

Code: Select all

[viking@viking60-server ~]$ inxi -t c
Processes: CPU - % used - top  5 active
           1: cpu: 60.0% command: hp-setup (started by: python2) pid: 1889

The workaround is simple:

Code: Select all

sudo kill -9 1889

This does not affect printing so all the functionality is there.

But what is the reason for this? Anyone having a high python2 (Htop will show it like python2 load while inxi is more specific) or hp-setup load constantly running?

[rolf]

Code: Select all

# urpmf hp-setup
hplip:/usr/bin/hp-setup

# urpmq -i hplip
Name        : hplip
Version     : 3.11.5
Release     : 2
Group       : System/Printing
Size        : 9860054                      Architecture: x86_64
Source RPM  : hplip-3.11.5-2.src.rpm
URL         : http://hplip.sourceforge.net/
Summary     : HP printer/all-in-one driver infrastructure
Description :
This is the HP driver package to supply Linux support for most
Hewlett-Packard DeskJet, LaserJet, PSC, OfficeJet, and PhotoSmart
printers and all-in-one peripherals (also known as Multi-Function
Peripherals or MFPs), which can print, scan, copy, fax, and/or access
flash memory cards.

It is work in progress, but printing, scanning, memory card access,
ink/toner/battery/consumable level checking, and inkjet printer
maintenance are supported on most models, when either connected to the
USB or LAN (built-in interfaces or selected HP JetDirect models) on a
Linux workstation with CUPS printing system.

For status and consumable checking and also for inkjet maintenance
there is the graphical tool "hp-toolbox" available (Menu:
"System"/"Monitoring"/"HP Printer Toolbox").

# urpmq -l hplip
/etc/cups/pstotiff.convs
/etc/dbus-1/system.d/com.hp.hplip.conf
/etc/hp
/etc/hp/hplip.conf
[..]


Do you have a Hewlett-Packard printer involved with this machine? I don't and I don't have hplip installed, so I have to use the urpm query commands to find out what files it contains, can't see inside of /etc/hp/hplip.conf. I'm not sure you need this software, even with an HP printer but, if you do, maybe there is some switch inside /etc/hp/hplip.conf

It looks like "setup" is hung up. Maybe call it with a -h or --help switch (after killing any running instance), to see if there's a clue how to configure it. I don't see a man page.

[viking60]

Thanks. This is a box with a HP-photosmart printer which is used as a network printer. It all works fine with cups. But a recent update lead to this strange result.
Looking at /etc/hp/hplip.conf now.....
And found a suspect right away - you are the Guru! Under dirs there is a path
run=/var/run
Now in arch they just did what most distros will do later (I think), and changed the path to /run leaving a symlink in /var/run this might be hard to digest so I will now change it to:
run=/run
in /etc/hp/hplip.conf
......
Tamtada dam Ramda dada dam.......

That was it!

[dedanna1029]

I'd call that a reportable bug if they have the symlinks wrong. Correct me if I'm wrong, but that should be fixed for others.

[viking60]

I don't think the symlinks are wrong. OTOH the conf setting should have worked with the symlink in place. I'll check it out...

[dedanna1029]

You had to change it, no?

so I will now change it to:
run=/run
in /etc/hp/hplip.conf

You also have a cause and effect here. Originally, before changing it, you were getting high CPU.

That spells bug to me.

[viking60]

Yes but I am unsure if it was a one time effect of the update that created the symlink and deleted /var/run while hp-lip was running!
That is the likely scenario when I think about it.
HP-lip could not be expected to switch while it was running.
I had to do this rather brutal thing:

Code: Select all

pacman -Syu --ignore filesystem && rm -rf /var/run /var/lock && \
    pacman -S filesystem

So it is mea culpa that I did not stop all the running jobs first.
In any case a reboot would have fixed it, because by then the symlink would have taken care of it Making my cry for help completely unnecessary - (but I did not know that at the time)

Rolfs help contributed to confuse me on yet a higher level though. Because I understand why now.
But a simple Windows behavior (reboot without even discovering the problem) would have taken care of it. So if I had paid less attention I would not even have discovered that this was a problem

[dedanna1029]

Question, should you have had to reboot in the first place, or ?

[viking60]

No I should have stopped all background tasks!