[opensuse-factory] xdpyinfo is using 100% of one cpu
Tw 20171218 the last several mornings I have one cpu pegged at 100% by xdpyinfo. Starts at 3:00am local time, but doesn't appear to be started by a cron job and I cannot locate a systemd timer that appears related. killing the two related xdpyinfo instances relieves the 100% cpu. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [12-21-17 07:52]:
Tw 20171218
the last several mornings I have one cpu pegged at 100% by xdpyinfo. Starts at 3:00am local time, but doesn't appear to be started by a cron job and I cannot locate a systemd timer that appears related.
killing the two related xdpyinfo instances relieves the 100% cpu.
sorry, should have included: X.Org version: 1.19.5 GeForce GTS 450/PCIe/SSE2 NVIDIA 387.34 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 21 Dec 2017, 13:59:18 +0100, Patrick Shanahan wrote:
* Patrick Shanahan <paka@opensuse.org> [12-21-17 07:52]:
Tw 20171218
the last several mornings I have one cpu pegged at 100% by xdpyinfo. Starts at 3:00am local time, but doesn't appear to be started by a cron job and I cannot locate a systemd timer that appears related.
killing the two related xdpyinfo instances relieves the 100% cpu.
sorry, should have included: X.Org version: 1.19.5 GeForce GTS 450/PCIe/SSE2 NVIDIA 387.34
can you reproduce this? If so, you should be using "ps -fHu <user-running-xdpyinfo> | grep -C 3 xdpyinfo" or "pstree | grep -C 3 xdpyinfo" to figure out which process was calling xdpyinfo. If that doesn't reveil the evil, you can try brute-force using find -x / /boot /var /usr /home -type f -print0 | xargs -0 -r fgrep -l xdpyinfo to get a list of files whose content reference "xdpyinfo". HTH, cheers. l8er manfred
* Manfred Hollstein <mhollstein@t-online.de> [12-21-17 08:11]:
On Thu, 21 Dec 2017, 13:59:18 +0100, Patrick Shanahan wrote:
* Patrick Shanahan <paka@opensuse.org> [12-21-17 07:52]:
Tw 20171218
the last several mornings I have one cpu pegged at 100% by xdpyinfo. Starts at 3:00am local time, but doesn't appear to be started by a cron job and I cannot locate a systemd timer that appears related.
killing the two related xdpyinfo instances relieves the 100% cpu.
sorry, should have included: X.Org version: 1.19.5 GeForce GTS 450/PCIe/SSE2 NVIDIA 387.34
can you reproduce this?
no, instances are owned by <user>, but starting an instance from cl completes displaying info to screen, and ends. the instances using 100% cpu do not end.
If so, you should be using "ps -fHu <user-running-xdpyinfo> | grep -C 3 xdpyinfo" or "pstree | grep -C 3 xdpyinfo" to figure out which process was calling
tomorrow I will do this.
xdpyinfo. If that doesn't reveil the evil, you can try brute-force using find -x / /boot /var /usr /home -type f -print0 | xargs -0 -r fgrep -l xdpyinfo
to get a list of files whose content reference "xdpyinfo".
running "brute-force" now. will advise. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [12-21-17 08:22]: [...]
xdpyinfo. If that doesn't reveil the evil, you can try brute-force using find -x / /boot /var /usr /home -type f -print0 | xargs -0 -r fgrep -l xdpyinfo
hickup, find does not like "-x" ?? presently running w/o. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 21 Dec 2017, 14:28:03 +0100, Patrick Shanahan wrote:
* Patrick Shanahan <paka@opensuse.org> [12-21-17 08:22]: [...]
xdpyinfo. If that doesn't reveil the evil, you can try brute-force using find -x / /boot /var /usr /home -type f -print0 | xargs -0 -r fgrep -l xdpyinfo
hickup, find does not like "-x" ?? presently running w/o.
sorry, "-x" is used by other tools to not descend directories on other filesystems. It's called "-xdev" for find... HTH, cheers. l8er manfred
On Thu, 21 Dec 2017, 15:00:52 +0100, Manfred Hollstein wrote:
On Thu, 21 Dec 2017, 14:28:03 +0100, Patrick Shanahan wrote:
* Patrick Shanahan <paka@opensuse.org> [12-21-17 08:22]: [...]
xdpyinfo. If that doesn't reveil the evil, you can try brute-force using find -x / /boot /var /usr /home -type f -print0 | xargs -0 -r fgrep -l xdpyinfo
hickup, find does not like "-x" ?? presently running w/o.
sorry, "-x" is used by other tools to not descend directories on other filesystems. It's called "-xdev" for find...
oh well... "paths must precede expression"... The proper command looks like: find / /boot /var /usr /home -xdev -type f -print0 | xargs -0 -r fgrep -l xdpyinfo HTH, cheers. l8er manfred
* Patrick Shanahan <paka@opensuse.org> [12-21-17 08:22]:
* Manfred Hollstein <mhollstein@t-online.de> [12-21-17 08:11]:
On Thu, 21 Dec 2017, 13:59:18 +0100, Patrick Shanahan wrote:
* Patrick Shanahan <paka@opensuse.org> [12-21-17 07:52]:
Tw 20171218
the last several mornings I have one cpu pegged at 100% by xdpyinfo. Starts at 3:00am local time, but doesn't appear to be started by a cron job and I cannot locate a systemd timer that appears related.
killing the two related xdpyinfo instances relieves the 100% cpu.
sorry, should have included: X.Org version: 1.19.5 GeForce GTS 450/PCIe/SSE2 NVIDIA 387.34
can you reproduce this?
no, instances are owned by <user>, but starting an instance from cl completes displaying info to screen, and ends. the instances using 100% cpu do not end.
If so, you should be using "ps -fHu <user-running-xdpyinfo> | grep -C 3 xdpyinfo" or "pstree | grep -C 3 xdpyinfo" to figure out which process was calling
tomorrow I will do this.
xdpyinfo. If that doesn't reveil the evil, you can try brute-force using find -x / /boot /var /usr /home -type f -print0 | xargs -0 -r fgrep -l xdpyinfo
to get a list of files whose content reference "xdpyinfo".
running "brute-force" now.
will advise.
found culprit, tks I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' ) for some reason the xdpyinfo instance persists. I have the same software running on my server but with an ati card. guess I need to try a different nvidia driver version as I didn't have the problem until recently and the current driver is also recent. tks for the help. If the driver change doesn't solve it, I'll be back. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2017-12-21 15:46, Patrick Shanahan wrote:
I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' )
for some reason the xdpyinfo instance persists.
So, does your script have DISPLAY set when it shouldn't? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Jan Engelhardt <jengelh@inai.de> [12-21-17 14:45]:
On Thursday 2017-12-21 15:46, Patrick Shanahan wrote:
I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' )
for some reason the xdpyinfo instance persists.
So, does your script have DISPLAY set when it shouldn't?
backintime in ~/.local/share/backintime/cron_env shows: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0 KDE_FULL_SESSION=true XAUTHORITY=/tmp/xauth-1000-_0 so, I guess that would be "yes", but I don't know that it shouldn't ??? or, if in fact that does set $DISPLAY. suggestions welcome, I know *nearly* nothing :) tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 21 décembre 2017 à 15:21 -0500, Patrick Shanahan a écrit :
* Jan Engelhardt <jengelh@inai.de> [12-21-17 14:45]:
On Thursday 2017-12-21 15:46, Patrick Shanahan wrote:
I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' )
for some reason the xdpyinfo instance persists.
So, does your script have DISPLAY set when it shouldn't?
backintime in ~/.local/share/backintime/cron_env shows: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0 KDE_FULL_SESSION=true XAUTHORITY=/tmp/xauth-1000-_0
so, I guess that would be "yes", but I don't know that it shouldn't ??? or, if in fact that does set $DISPLAY.
suggestions welcome, I know *nearly* nothing :)
Honestly, doing this kind of hacks to detect if X is running is really broken (you could be logged on another display, XAUTHORITY file might be at another non-guessable location, if you use gdm, for instance, etc..) It would be much better to query logind through loginctl to see if user "whatever" has a session open (or through dbus call to logind). -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Frederic Crozat <fcrozat@suse.com> [12-22-17 03:24]:
Le jeudi 21 décembre 2017 à 15:21 -0500, Patrick Shanahan a écrit :
* Jan Engelhardt <jengelh@inai.de> [12-21-17 14:45]:
On Thursday 2017-12-21 15:46, Patrick Shanahan wrote:
I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' )
for some reason the xdpyinfo instance persists.
So, does your script have DISPLAY set when it shouldn't?
backintime in ~/.local/share/backintime/cron_env shows: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0 KDE_FULL_SESSION=true XAUTHORITY=/tmp/xauth-1000-_0
so, I guess that would be "yes", but I don't know that it shouldn't ??? or, if in fact that does set $DISPLAY.
suggestions welcome, I know *nearly* nothing :)
Honestly, doing this kind of hacks to detect if X is running is really broken (you could be logged on another display, XAUTHORITY file might be at another non-guessable location, if you use gdm, for instance, etc..)
It would be much better to query logind through loginctl to see if user "whatever" has a session open (or through dbus call to logind).
you are speaking above me :(. and if the hangng xdpyinfo instance is to determine a graphic session open, what use is it for a "text" application, backintime is a python script? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [12-21-17 15:24]:
* Jan Engelhardt <jengelh@inai.de> [12-21-17 14:45]:
On Thursday 2017-12-21 15:46, Patrick Shanahan wrote:
I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' )
for some reason the xdpyinfo instance persists.
So, does your script have DISPLAY set when it shouldn't?
backintime in ~/.local/share/backintime/cron_env shows: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0 KDE_FULL_SESSION=true XAUTHORITY=/tmp/xauth-1000-_0
so, I guess that would be "yes", but I don't know that it shouldn't ??? or, if in fact that does set $DISPLAY.
suggestions welcome, I know *nearly* nothing :)
fvogt suggested on irc that I run "gdb -p $(pidof xdpyinfo)" when the xdpyinfo instance is present. output at: http://wahoo.no-ip.org/~paka/xdpyinfo.gdb.txt + thread apply all bt http://wahoo.no-ip.org/~paka/xdpyinfo.gdb2.txt also strace -p $(pidof xdpyinfo) http://wahoo.no-ip.org/~paka/xdpyinfo.strace.txt -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [12-22-17 08:10]:
* Patrick Shanahan <paka@opensuse.org> [12-21-17 15:24]:
* Jan Engelhardt <jengelh@inai.de> [12-21-17 14:45]:
On Thursday 2017-12-21 15:46, Patrick Shanahan wrote:
I have a python backup instance runs at 3am every day, backintime: /usr/share/backintime/common/tools.py def check_x_server(): return 0 == os.system( 'xdpyinfo >/dev/null 2>&1' )
for some reason the xdpyinfo instance persists.
So, does your script have DISPLAY set when it shouldn't?
backintime in ~/.local/share/backintime/cron_env shows: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0 KDE_FULL_SESSION=true XAUTHORITY=/tmp/xauth-1000-_0
so, I guess that would be "yes", but I don't know that it shouldn't ??? or, if in fact that does set $DISPLAY.
suggestions welcome, I know *nearly* nothing :)
fvogt suggested on irc that I run "gdb -p $(pidof xdpyinfo)" when the xdpyinfo instance is present. output at: http://wahoo.no-ip.org/~paka/xdpyinfo.gdb.txt + thread apply all bt http://wahoo.no-ip.org/~paka/xdpyinfo.gdb2.txt
also strace -p $(pidof xdpyinfo) http://wahoo.no-ip.org/~paka/xdpyinfo.strace.txt
Bug 1073996 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Frederic Crozat -
Jan Engelhardt -
Manfred Hollstein -
Patrick Shanahan