[indiana-discuss] evince hangs in b101 after suspend-resume

[Brian Cameron]

Does running evince from a command-line terminal generate any useful
error or warning messages?  What version of Solaris and GNOME are you
using?

Note that ORBit2 is a CORBA service used by many GNOME applications.
It is used for general IPC (inter-process communication) purposes.
GConf does use it, but so do lots of other things in GNOME.  Normally
if you get a "ECONNREFUSED" error, this means that a process which
is the CORBA service is failing to connect, perhaps because it crashed.
Without knowing what specific service is causing the problem here, it
is hard to speculate what the problem might be.

Note the /etc/orbitrc file and $HOME/.orbitrc), which contains ORBit-2
configuration.  Note that by default this file contains lines like
"ORBLocalOnly=1" and "ORBIIOPIPNAME=127.0.0.1".  These lines ensure
that only processes on the local machine can talk via ORBit2.  You
might try relaxing these configuration settings, or trying different
ORBit2 configuration settings to see if that makes things work better.

   http://orbit-resource.sourceforge.net/faq.html

Note that GConf is the GNOME Configuration daemon.  Most GNOME-based
programs use it for storing user preferences.  So if you make changes
in a GNOME program's preferences dialog, the changes are probably saved
via GConf to your $HOME/.gconf directory.  Evince probably does use
GConf like this, and GConf does use ORBit2.  However, it seems that we
are speculating that the ORBit2 problems you are seeing are GConf
related.  Evince may use ORBit2 for other purposes also, so probably
better to not speculate too much about what is causing the problem
here.

GConf runs as process named "/usr/lib/gconfd-2".  If programs are
having trouble connecting to the GConf daemon, then I would make sure
it is running.  If it is not running for some reason, it should
normally autostart when programs call GConf functions.  If it is hung,
then killing the gconfd-2 process might get things working again,
and would be worth a try.

Note that starting with GNOME 2.24 (used in the latest OpenSolaris
08.11 release) GConf depends on D-Bus.   So you need D-Bus running
in your session for programs which use GConf to work.  Normally this
D-Bus sesssion is started up for you when the GNOME session starts.
However, if D-Bus is not running, then this could cause problems.
Also, if you are trying to run programs like evince outside of a
GNOME session (via remote telnet, in a CDE session, etc.) then you
would also have similar troubles, since D-Bus is not normally started
by default outside of the user session.

Running evince like this should ensure that a new D-Bus session is
started.  This will ensure that D-Bus is available.  Let me know if
this works better.

   dbus-launch --exit-with-session evince

I am not sure why a suspend-resume would cause these sorts of odd
problems.  However, I wanted to give you pointers to how to
configure ORBit2 and how to run programs with dbus-launch, and
some other pointers that might help make things work again.  If
we can identify some technique that makes it work better again,
then this information should help to track down what the problem
might be.

Brian


>> correcxtion: the problem arises now when i'm trying to go into
>> submenus of evince, and truss reveals the same port and unix socket
>> concerned:
>> /1: connect(23, 0x08857618, 16, SOV_DEFAULT) Err#146 ECONNREFUSED
>> /1: AF_INET name = 127.0.0.1 port = 46541
>> /1: close(23) = 0
>> /1: so_socket(PF_UNIX, SOCK_STREAM, 0, 0x00000000, SOV_DEFAULT) = 23
>> /1: fcntl(23, F_SETFL, FNONBLOCK) = 0
>> /1: fcntl(23, F_SETFD, 0x00000001) = 0
>> /1: getuid() = 101 [101]
>> /1: connect(23, 0x087DD648, 48, SOV_DEFAULT) Err#146 ECONNREFUSED
>> /1: AF_UNIX name = /var/tmp/orbit-henry/linc-2d4-0-49a39032c7fd8
>> /1: close(23) = 0
>> /1: so_socket(PF_UNIX, SOCK_STREAM, 0, 0x00000000, SOV_DEFAULT) = 23
>
> On my system, the /var/tmp/orbit-* socket files seem to be applications
> connected to the /usr/lib/gconfd-2 process.
> Do you have a gconfd-2 process running? If so, you could try trussing it
> to see if it looks wedged.
> My gconfd-2 is also listening on a TCP port, although not the same port
> number as your connections are trying, but that might be dynamically
> chosen. I suspect applications may try the TCP connection if the named
> pipe connection fails, as there don't seem to be any actual TCP
> connections to my gconfd-2 process.
>
> As to what gconfd-2 does, I've no idea.
>