Bug 697152

Summary: [abrt] xhotkeys-0.9.8.3-7.fc12: __init__.py:52:_init:RuntimeError: could not open display
Product: [Fedora] Fedora Reporter: J <pepensado>
Component: xhotkeysAssignee: Christoph Wickert <cwickert>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: cwickert
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: abrt_hash:4f66cc03
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-17 18:14:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace none

Description J 2011-04-16 08:04:05 UTC
abrt version: 1.1.17
architecture: i686
cmdline: /usr/bin/python /usr/bin/xhotkeys
component: xhotkeys
executable: /usr/bin/xhotkeys
kernel: 2.6.35.11-83.fc14.i686
package: xhotkeys-0.9.8.3-7.fc12
reason: __init__.py:52:_init:RuntimeError: could not open display
release: Fedora release 14 (Laughlin)
time: 1302940862
uid: 500

backtrace
-----
__init__.py:52:_init:RuntimeError: could not open display

Traceback (most recent call last):
  File "/usr/bin/xhotkeys", line 36, in <module>
    import gtk, gtk.glade, gobject
  File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
    _init()
  File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
    _gtk.init_check()
RuntimeError: could not open display

Local variables in innermost frame:
sys: <module 'sys' (built-in)>
sys_path: ['/usr/bin', '/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/PIL', '/usr/lib/python2.7/site-packages/gst-0.10', '/usr/lib/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/site-packages/webkit-1.0']

How to reproduce
-----
1. Since xhotkeys was not starting at boot, I loaded it into a cron job, to start at boot (@reboot) and then every 1 minute.
2.
3.

Comment 1 J 2011-04-16 08:04:07 UTC
Created attachment 492548 [details]
File: backtrace

Comment 2 Christoph Wickert 2011-04-16 08:12:29 UTC
cronjobs don't know environment variables, this means you need to specify DISPLAY manually in the job.

But I think a cronjob is a fundamentally broken approach here, you should use some autostart mechanism as /etc/xdg/autostart or ~/.config/autostart. Depending on your window manager or desktop environment there may be additional/other mechanism. What kind of session are you running?

Comment 3 J 2011-04-16 20:09:35 UTC
Package: xhotkeys-0.9.8.3-7.fc12
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Nothing in particular.
2.
3.

Comment 4 J 2011-04-16 20:17:15 UTC
(In reply to comment #2)
> cronjobs don't know environment variables, this means you need to specify
> DISPLAY manually in the job.
> 
> But I think a cronjob is a fundamentally broken approach here, you should use
> some autostart mechanism as /etc/xdg/autostart or ~/.config/autostart.
> Depending on your window manager or desktop environment there may be
> additional/other mechanism. What kind of session are you running?

The use of a cronjob was a workaround to the reported bug:

http://savannah.nongnu.org/support/?106315

I already tried running "xhotkeys", "xhotkeys d" or "xhotkeys sighup" (as the man page says: http://linux.die.net/man/1/xhotkeys) with gnome-session-properties but it does not start.

Comment 5 Christoph Wickert 2011-04-16 22:31:22 UTC
(In reply to comment #4)
> The use of a cronjob was a workaround to the reported bug:
> 
> http://savannah.nongnu.org/support/?106315

I see no mention of a cronjob in that bug report.

> I already tried running "xhotkeys", "xhotkeys d" or "xhotkeys sighup" (as the
> man page says: http://linux.die.net/man/1/xhotkeys) with
> gnome-session-properties but it does not start.

xhotkeys works fine here, according to 'ps' it is running. There is no 'd' option and SIGHUP is not a command line option wither but a signal that needs to be sent by the 'kill' command. Did you try '-c' for the graphical config tool.

BTW: Why are you running xhotkeys in GNOME? GNOME has it's own tool called gnome-keybinding-properties.

Comment 6 J 2011-04-17 17:17:41 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > The use of a cronjob was a workaround to the reported bug:
> > 
> > http://savannah.nongnu.org/support/?106315
> 
> I see no mention of a cronjob in that bug report.
> 
> > I already tried running "xhotkeys", "xhotkeys d" or "xhotkeys sighup" (as the
> > man page says: http://linux.die.net/man/1/xhotkeys) with
> > gnome-session-properties but it does not start.
> 
> xhotkeys works fine here, according to 'ps' it is running. There is no 'd'
> option and SIGHUP is not a command line option wither but a signal that needs
> to be sent by the 'kill' command. Did you try '-c' for the graphical config
> tool.
> 
> BTW: Why are you running xhotkeys in GNOME? GNOME has it's own tool called
> gnome-keybinding-properties.

Well, such a straight forward solution I had not considered: the use of Gnome's own keyboard short-cuts (I'm still a rookie in Linux). I thank you so much for your insight. Now my customized hot-keys work just great without the need of xhotkeys.

It is still a mystery to me that the xhotkeys daemon does not start under gnome-session-properties and that it crashes (the xhotkeys -c option does work well and opens the GUI). But well, xhotkeys was a workaround itself since the very beginning.

Thank you and greetings.

Comment 7 Christoph Wickert 2011-04-17 18:14:16 UTC
No problems, you are welcome.

I have no idea, if/why xhotkeys doesn't work in GNOME, but I don't consider this a bug. Also crashing  when there is no display is typical for python programs. And last but not least xhotkeys is no longer actively developed, so forwarding this crash report to the developers doesn't make much sense.

Therefore I'm now going to close this bug.