Thanks to all who responded:
Toni L. Harbaugh-Blackford (harbaugh_at_ncifcrf.gov)
Ron Bowman Techno-Sciences, Inc. (rdbowma_at_tsi.clemson.edu)
Richard Frank (rnfrank_at_llnl.gov)
Sorry for the delay but I wanted to try the solutions and collate any
more suggestions.
Original Question:
>I have this strange error message appearing on the system console.
>Even though it claims tooltalk is not installed it surely is. Has
>anyone had a similar problem or explain why it happens ?
>
># the following appears in /var/adm/syslog.dated/user.log
>
> Jun 16 15:25:51 PBP50505 syslog: libtt[22172]:
>ttdt_Xt_input_handler():
> tttk_message_receive(): TT_ERR_NOMP^INo ttsession process is
>running, probably because tt_open() has not been called yet. If this
>code is returned from tt_open() it means ttsession could not be
>started, which generally means ToolTalk is not installed on this
>system.
> Jun 16 15:27:17 PBP50505 syslog: libtt[24716]:
>ttdt_Xt_input_handler(): tttk_message_receive(): TT_ERR_NOMP^INo t
> tsession process is running, probably because tt_open() has not
>been called yet. If this code is returned from tt_open() it means
>ttsession could not be started, which generally means
> ToolTalk is not installed on this system.
> Jun 16 15:27:56 PBP50505 syslog: libtt[11471]:
>ttdt_Xt_input_handler():
> tttk_message_receive(): TT_ERR_NOMP^INo ttsession process is
>running, probably because tt_open() has not been
> called yet. If this code is returned from tt_open() it means
>ttsession could not be started, which generally
>means
> ToolTalk is not installed on this system.
> Jun 16 15:27:56 PBP50505 syslog: libtt[11471]:
>ttdt_Xt_input_handler():
> tttk_message_receive(): TT_ERR_NOMP^INo t
> tsession process is running, probably because tt_open() has not
>been called yet. If this code is returned from tt_open() it means
>ttsession could not be started, which generally means
> ToolTalk is not installed on this system.
Summary
=======
I have had some responses, one of which checks out after testing it. If
the user exits the CDE session without closing any third party tooltalk
aware applications the connection between ttsession and the application
is broken. This causes the tooltalk application to generate these
messages as it tries to restablish a connection. Sure enough this
generated a similar error in the log file. This seems to be the most
favorable explanation.
Another response suggested that third party software components may not
be fully integrated with tooltalk when it was installed. I ran up an
application, terminated it and then exited from CDE to see if these
messages occurred.
If the third party products had not been properly integrated these
messages would not appear because they were not there to generate them
when ttsession terminated. They did indeed disappear, but them I had
all sorts of problems trying to get the CDE environment to work again
when I tried to start up again. Eventually I rebooted to recover.
As Toni said (see below) it would be nice if there were a way of
reducing the syslog priority level of these messages; the system
administrator could filter them out without other system messages being
"buried".
In the configuration file "/etc/syslog" the facility could be changed
from
user.debug /var/adm/syslog.dated/user.log
to
user.error /var/adm/syslog.dated/user.log
or
user.warn /var/adm/syslog.dated/user.log
However this may well lose some messages from other modules.
I haven't found a way to ignore these specific tooltalk messages.
Responses:
=========
(1) This problem first appeared under 4.0B, and as yet has not be
resolved for 4.0D even with the latest patch kit.
This happens when logging out of CDE if the CDE ttsession process dies
*before* any of the processes that 'talk' to it. The only way I have
been able to avoid generating these messages myself is to close *all*
the applications I have open *BEFORE* exiting CDE. Of course, this can
be a pain if you have a lot of applications running. Also, if you
manage a large system it is likely that your users will not know to do
this (and probably wouldn't do it even if they did know).
Two years ago when we first got our AlphaServer 8400 I posed the same
question to DEC support (who actually came onsite because we were having
repeated crashes of our new system) and they looked at me like I was
crazy. After I demonstrated the problem to them, they said that they
would work to resolve the issue, but nothing ever came of it.
It would be enough if DEC would just reduce the syslog priority level of
these messages, so that people who don't want to see them could filter
them out *without* losing other truly IMPORTANT messages. I log to a
fairly high degree, so the syslog priority would have to be reduced to
*.debug in order for me to filter out these messages.
If anyone has found a solution to this - of *ANY* kind - please post a
summary.
Thanks
Toni L. Harbaugh-Blackford
harbaugh_at_ncifcrf.gov
(2) …………. It appears to me (pure speculation) that the error occurs for
certain software when certain parts of the software are used. Almost as
if a call is being made incorrectly or that something has changed from
the version of ToolTalk I use and the version the software was written
for. Fortunately, I can detect no problems (performance wise ) with the
errors - another reason for ignoring them.
Ron Bowman
Techno-Sciences, Inc.
rdbowma_at_tsi.clemson.edu
864-646-4028
(3) When the ttsession exits before the tooltalk clients the connection
between them (via an ipc socket channel) is broken, so the tooltalk
messages have nowhere to go. They should have been delivered before the
ttsession terminated.
These messages are generated by the tooltalk clients. The message
Jun 16 15:25:51 PBP50505 syslog: libtt[22729]:
_Tt_rpc_client::init(): fcntl(F_SETFD): m
is generated by the tooltalk aware client dtexec. dtexec does not
terminate when it loses its connection to tooltalk. dtexec is probing
the socket file descriptor by doing a fcntl system call in order to
determine tooltalk's status.
The other message
tttk_message_receive(): TT_ERR_NOMP^INo ttsession process is running,
probably because tt_open() has not been called yet. If this code is
returned from tt_open() it means ttsession could not be started, which
generally means ToolTalk is not installed on this system.
is also being generated by a tooltalk client. This is due to the broken
interconnection with ttsession.
These messages don't appear if the clients exit first.
Thanks again,
Ian
______________________________________________________
Get Your Private, Free Email at
http://www.hotmail.com
Received on Tue Aug 11 1998 - 15:15:25 NZST