|Summary:||print/hplip: zombie process|
|Product:||Ports & Packages||Reporter:||Dušan Vejnovič <freebsd>|
|Component:||Individual Port(s)||Assignee:||Tijl Coosemans <tijl>|
|Severity:||Affects Only Me||CC:||chris, freebsd, guru, makc, soho14, w.schwarzenfeld, woodsb02|
Description Dušan Vejnovič 2015-07-20 16:32:07 UTC
> uname -ar FreeBSD xxxx.dussan.org 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 firstname.lastname@example.org:/usr/obj/usr/src/sys/GENERIC amd64 I'm using XFCE as DE. After login in XFCE desktop, the task manager show zombie process: /usr/local/bin/python2.7 /usr/local/bin/hp-upgrade --check
Comment 1 Max Brazhnikov 2015-07-22 12:16:31 UTC
(In reply to Dušan Vejnovič from comment #0) > I'm using XFCE as DE. After login in XFCE desktop, the task manager show > zombie process: > /usr/local/bin/python2.7 /usr/local/bin/hp-upgrade --check Could you run '/usr/local/bin/hp-upgrade --check -g' and see how far it goes.
Comment 2 Dušan Vejnovič 2015-07-22 15:48:52 UTC
(In reply to Max Brazhnikov from comment #1) if I run as regular user the output is in attachment. But also got this text out on terminal: cat: /etc/issue: No such file or directory warning: distro is not found in AUTH_TYPES
Comment 3 Dušan Vejnovič 2015-07-22 15:50:32 UTC
Created attachment 159069 [details] log of hp-upgrade --check -g
Comment 4 Max Brazhnikov 2015-07-23 10:11:50 UTC
(In reply to Dušan Vejnovič from comment #2) > But also got this text out on terminal: > cat: /etc/issue: No such file or directory > warning: distro is not found in AUTH_TYPES You may ignore this. According to the log hp-upgrade works as intended. Is the problem always reproducible? I have no idea what causes the problem, but you can debug it yourself. hp-upgrade is executed by hp-systray, which is started by XFCE via /usr/local/etc/xdg/autostart/hplip-systray.desktop. You can add '-g' to the Exec line in hplip-systray.desktop and look for the output in ~/.xsession-errors.
Comment 5 Dušan Vejnovič 2015-07-23 18:08:56 UTC
(In reply to Max Brazhnikov from comment #4) The problem is reproducible: I log out from DE and log back. I did as you write but no output in ~/.xsession-errors and no file with that name. Zombie process is still visible in the task manager. But I notice this in /var/log/messages: Jul 23 19:50:03 xxxx hp-systray: hp-systray: error: option -s not recognized Jul 23 19:50:13 xxxx hp-upgrade: hp-upgrade: warning: distro is not found in AUTH_TYPES
Comment 6 Matthias Apitz 2016-03-30 05:36:16 UTC
I have a similar situation on CURRENT: $ uname -a FreeBSD c720-r292778-amd64 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292778: Mon Dec 28 05:45:37 CET 2015 root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC amd64 $ ps ax | fgrep hp 1487 - Is 0:00,98 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x 1580 - S 0:00,17 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x 1581 - S 0:00,08 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x 2266 - Ss 0:00,01 /bin/sh -c (ps ax | fgrep hp) >/tmp/vR1JcEA/1 2>&1 2268 - S 0:00,00 fgrep hp $ fgrep hp- /var/log/messages Mar 29 07:06:44 c720-r292778-amd64 hp-upgrade: hp-upgrade: warning: distro is not found in AUTH_TYPES Mar 29 20:07:58 c720-r292778-amd64 hp-systray: hp-systray: error: option -s not recognized Mar 29 20:08:09 c720-r292778-amd64 hp-upgrade: hp-upgrade: warning: distro is not found in AUTH_TYPES Mar 30 07:17:08 c720-r292778-amd64 hp-systray: hp-systray: error: option -s not recognized Mar 30 07:17:16 c720-r292778-amd64 hp-upgrade: hp-upgrade: warning: distro is not found in AUTH_TYPES (the above times are times of reboot) ]$ pkg info | fgrep hplip hplip-3.14.10_1 Drivers and utilities for HP Printers and All-in-One devices from time to time (not aleways) the proc 'hp-systray' becomes a zombie:
Comment 7 Matthias Apitz 2016-03-30 07:14:53 UTC
re/ hp-systray, I have poked around in my KDE4 desktop system and see the following: - the installation of the port installs a desktp file in /usr/local/etc/xdg/autostart/hplip-systray.desktop - on 1st KDE start after installation this brings up the processes: $ ps ax | fgrep hp-sys 8924 - Ss 0:00,94 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x 9008 - S 0:00,14 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x 9010 - S 0:00,05 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x - if one now stops KDE4 regulary a file is left about the last session which contains for hp-systray: $ fgrep hp-sys .kde4/share/config/ksmserverrc program6=/usr/local/bin/hp-systray restartCommand6=/usr/local/bin/hp-systray,-session, 10125175108105000145932053700000077400011_1459321127_684235 i.e. the command to be restarted; note the -session, ... - if one now restarts KDE4 it gives errors about the wrong -s flag: $ fgrep hp-sys /var/log/messages | tail -3 Mar 29 20:07:58 c720-r292778-amd64 hp-systray: hp-systray: error: option -s not recognized Mar 30 07:17:08 c720-r292778-amd64 hp-systray: hp-systray: error: option -s not recognized Mar 30 08:59:38 c720-r292778-amd64 hp-systray: hp-systray: error: option -s not recognized but hp-systray is then started by the *.desktop file;
Comment 8 Mo Sommer 2016-03-30 15:45:04 UTC
$ uname -a FreeBSD xxxxx 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292778: Mon Dec 28 05:45:37 CET 2015 root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC amd64 hplip version: hplip-3.14.10_1 I also have this problem that 'hp-systray' becomes a zombie. $ ps axl | fgrep Z UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 1001 4292 4079 0 52 0 0 0 - Z - 0:00,92 <defunct> $ ps ax 4079 PID TT STAT TIME COMMAND 4079 - Is 0:00,60 /usr/local/bin/python2.7 /usr/local/bin/hp-systray -x This is reproducible and happens after every login in KDE4. But no message about "option -s not recognized" in /var/log/messages.
Comment 9 Mr Pettington 2017-02-25 13:23:58 UTC
I am the original porter of hplip 3.x, hplip is one of those stupid programs that needs x to be defined in order to work or else it dies. I plan on updating this to the latest and I will see if I can fix/debug this issue.
Comment 10 Walter Schwarzenfeld 2019-09-04 23:18:25 UTC
We have version 3.17.11_5. Does this problem still exist?
Comment 11 Ben Woods 2020-09-03 09:18:00 UTC
Update assignee inline with new port maintainer