I have a strange situation which is repeated on 2 SLED11 SP1 machines. The users both use the Gnome desktop. When they start one of our centrally served applications (eg Tecplot, Fluent Icemcfd) the app starts to open, the splash screen appears and disappears and the application window opens. Then the desktop freezes, the start menu does not work etc. If I then use CTRL-ALT-F1 and login as the user in the text terminal, use kill -9 to kill the application and then return to the X session with CTRL-ALT-F7 the desktop is usable again. If I then start the same application again, it works, as do all the others. I only have to start one application, have it fail and kill it for all the other applications to subsequently work. This carries on until the users logs out and in again, when we have to go through the kill process again. It doesn’t matter which application is started and killed, after it is done all the others work.
This does not happen when the user uses a KDE4 desktop. In that instances all the applications work as they should from the first login.
This has me baffled and any advice would be appreciated.
[QUOTE=malcolmlewis;2305]Hi
If you open a terminal and start the application, see any output? Else
check the ~/.xsession-errors file for clues.
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.1 (x86_64) Kernel 3.1.9-1.4-desktop
up 1 day 7:49, 4 users, load average: 0.04, 0.04, 0.07
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU[/QUOTE]
Malcolm
.xsession errors contains the following, after the app has been started and hung:
chown: changing ownership of /dev/xconsole': Operation not permitted chmod: changing permissions of /dev/xconsole’: Operation not permitted
/etc/X11/xim: Checking whether an input method should be started.
/etc/X11/xim: use GDM_LANG=en_GB.UTF-8
sourcing /etc/sysconfig/language to get the value of INPUT_METHOD
INPUT_METHOD is not set or empty (no user selected input method).
Trying to start a default input method for the locale en_GB.UTF-8 …
There is no default input method for the current locale.
Dummy input method “none” (do not use any fancy input method by default)
GNOME_KEYRING_SOCKET=/tmp/keyring-hoCWHE/socket
SSH_AUTH_SOCK=/tmp/keyring-hoCWHE/socket.ssh
** (gnome-settings-daemon:6997): WARNING **: Can not run apport-checkreports
(gnome-settings-daemon:6997): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)’ failed
Window manager warning: Failed to read saved session file /home/ttmr2/.config/metacity/sessions/105bf90433a3698660132940566251808800000068060023.ms: Failed to open file ‘/home/ttmr2/.config/metacity/sessions/105bf90433a3698660132940566251808800000068060023.ms’: No such file or directory
Initializing nautilus-share extension
Initializing nautilus-open-terminal extension
** (bluetooth-applet:7086): WARNING **: Could not open RFKILL control device, please verify your installation
Failure: Module initalization failed
** (nautilus:7045): WARNING **: Unable to add monitor: Not supported
Nautilus-Share-Message: REFRESHING SHARES
Nautilus-Share-Message: ------------------------------------------
Nautilus-Share-Message: spawn arg “net”
Nautilus-Share-Message: spawn arg “usershare”
Nautilus-Share-Message: spawn arg “info”
Nautilus-Share-Message: end of spawn args; SPAWNING
Nautilus-Share-Message: returned from spawn: SUCCESS:
Nautilus-Share-Message: exit code 255
Nautilus-Share-Message: ------------------------------------------
Nautilus-Share-Message: Called “net usershare info” but it failed: ‘net usershare’ returned error 255: net usershare: usershares are currently disabled
Nothing in that .xsession-errors looks like it would be related to an application crash. (There’s always some errors in there!)
You could try taking copy of the .xsession-errors file before you run the application, then comparing the two files after the application has hung to see if anything new has been added.
You could also try running the application under strace. Sometimes there’s useful clues in the output of strace as to what’s going wrong.
$ strace -f -o /tmp/straceoutput command
The output of strace will end up in /tmp/straceoutput
Are you using metacity of compiz as the window manager? Or to put it another way, do you have Desktop effects enabled? If you have Desktop Effects enabled you’re using compiz, if you have them disabled you’re using metacity. Desktop Effects is enabled by default when you log in if it’s determined that your hardware supports it.
You can always check with
$ ps U $USER | grep -i metacity
$ ps U $USER | grep -i compiz
E.g.
me@mine:~/SLED11SP2> ps U $USER | grep -i compiz
6872 ? S 0:00 /bin/sh /usr/bin/compiz-manager
6954 ? S 8:12 /usr/bin/compiz --ignore-desktop-hints ccp
me@mine:~/SLED11SP2> ps U $USER | grep -i metacity
3794 pts/5 S+ 0:00 grep -i metacity
me@mine:~>
If you have Desktop Effects enabled try turning them off (look in the Control Panel) and see if you still get the crashes. I’ve hacked the machines I managed so that Desktop Effects are off by default because early on when SLED 11 was first released some apps were causing Compiz to crash. (I think that’s fixed now but I’ve never changed back to having Desktop Effects enabled by default.)
If you’re posting the content of files or output of commands, putting CODE tags around it makes it more readable. (Look for the # button when composing your post.)
Hi
Looks like it maybe these metacity sessions, can you enable desktop
effects on these systems to use compiz and see if that makes a
difference? Else if already running desktop effects, disable them.
–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.19-default
up 13:05, 2 users, load average: 0.07, 0.07, 0.06
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU