From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Description of problem: Sometime mc can't start because of a gpm socket blocking. When it happens again, i will include a strace. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: Not reproducable Actual Results: blank screen appears but no mc Expected Results: mc appearing Additional info: stopping gpm service will "solve" the problem.
*** Bug 168077 has been marked as a duplicate of this bug. ***
I haven't seen such behaviour of mc so far, so please include strace, your mc and gpm versions. Also a test case, when this happens every time would be good to let me reproduce it.
All my colleagues do have these problems. I only saw it on desktop usage so far. As stated in my first post, I will include a strace when it hangs again :) Versions: mc-4.6.1a-0.11.FC4 gpm-1.20.1-71
Seems like it turned stable after you reported the bug here ;) [still waiting for a strace]
He I finally got it again :) Here are the last strace lines, it keeps hanging on the /dev/gpmctl. After shutting down gpm mc starts up again :) readlink("/proc/self/fd/0", "/dev/pts/10", 4095) = 11 open("/dev/pts/10", O_WRONLY) = 5 ioctl(5, TIOCGWINSZ, {ws_row=55, ws_col=155, ws_xpixel=0, ws_ypixel=0}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 6 connect(6, {sa_family=AF_FILE, path="/dev/gpmctl"}, 13
Ok, seen a similar problem recently. Just killing gpm before mc solves the problem for me. However, this seems more like gpm problem IMO.
The problem is reproducible when gpm is running, user is logged to X Window and the same user is trying to run mc via ssh connection. I just restarted gpm when gpm hanged and now I'm not able to reproduce so some other action should be made (mabe logout/login to the X or so).
*** Bug 163061 has been marked as a duplicate of this bug. ***
Bug #172921 has been opened for this gpm bug (under RHEL4 so this may be better to open the same bug for FC4 or for upcoming FC5).
Ok, gpm dependency removed and mc is no more compiled with gpm support since mc-4.6.1a-0.15.FC4.
From User-Agent: XML-RPC mc-4.6.1a-0.15.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
(for comment #10): Jindrich, I had the same issue as in comment #7 . Invoking mc with `-d' option solves this issue ("mc -d" -- disable gpm at runtime). As actually for most Fedora users "mc" is an alias for /usr/share/mc/bin/mc-wrapper.sh, it looks more easy and correct just to add `-d' option somewhere in that script, rather than disable gpm completely at compile time...
Dmitry, thanks for the comment, maybe fixing the wrapper scripts would cause less pain to users that still want to use the mc with the gpm support enabled.
The problem is that the -d option disables the mouse support completely what we don't want. We need to disable only the mouse support for gpm and mc doesn't have an option for that. It's bad as the xterm mouse support works fine on gnome-terminal/xterm/konsole but -d disables it completely. The only effect of the disabled gpm is that mouse services won't work on text console.
Well, What about something like: [ -n "$DISPLAY" ] && opts="-d" in the wrapper script?
Typo... :) [ -z "$DISPLAY" ] && opts="-d"
That won't help if you ssh to a machine from xterm then xterm support will still work, but DISPLAY won't be set you could however test for TERM==xterm.
As discussed in bug 168076 I've done a localbuild of mc with gpm support reanbled and now I've tried recreating the problem as described in bug 163061: -start pc with gdm and gpm (runlevel 5) -log into gdm as hans -log into console as hans -start mc, starts fine, mouse works fine -ssh to localhost as hans -start mc, the following message is printed over mc's screen: -- *** info [lib/liblow.c(458)]: EditWarning: closing connection -- and the mouse works as if mc has been compiled without gpmsupport, iow you can select parts of the screen but not control mc. -as root from another console do: service restart gpm -start mc again in the ssh session now the message is: *** warning [client.c(183)]: Failed gpm connect attempt by uid 500 for vc 0 *** info [lib/liblow.c(458)]: EditWarning: closing connection So I believe that this bug is now fixed somehow. Notice that since the version used by the reporter of this bug (4.6.1a-0.11) a lott of syncs with upstream have been done, so most likely this has been fixed / worked around upstream.
Some more digging has gotten some new insight, the messages shown I've reported in comment #18 are actually gpm and/or libgpm messages, so probably this is fixed in a newer gpm.
I have been digging around in this bug, but could not figure an easy solution. The problem apparently is that libgpm hangs on opening communication with gpm. If gpm hangs, the client will hang as well. It could be possibly worked around with a timeout, but the code is already somewhat hairy... I will think about it. Either that, or make gpm (daemon) not hang :-).
Erm, As I already reported this seems fixed, how can I reproduce this?
I would suspect that the "fix" is the fact that gpm support in mc is now disabled in fedora core. So the issue is not fixed, just worked around. I am not sure it is worth the effort to fix it for real, though :). For now, the "solution" is good enough. However, it will affect other apps than mc still, that use gpm mouse support.
I know gpm is disabled *by default* I build a local mc rpm however with it enabled and couldn't reproduce the problem. See above.
You mean comment #19? There were no updates to gpm since 2004.
Strange, maybe some change in mc then has fixed this? Like I said I can't reproduce it. And yes I meant comment 19 (and mostly 18)
fc4 is out of support and this has been worked around by disabling gpm in mc, therefor closing. I could try to fix it in RHEL4 though.
Oh, got it. Will start working on a fix...
mc-4.6.1a-36.20070124cvs.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
mc-4.6.1a-36.20070124cvs.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.