weird sa/master sysprocesses without host info 
Author Message
 weird sa/master sysprocesses without host info

This is one of the stranger things I've seen in 7 years of
Sybase administration.

A few months back we started getting these spid's{*filter*} around
one of our servers (the busiest one) with the suid identified
as sa and the database as master.  Sysprocesses shows no information
whatsoever as to a hostname, program_name, host process id.

These tend to accumulate.

Server is 4.9.1 running on Sparc 10 SunOS 4.3.  Clients are
SunOS 4.3, NT Workstation 3.5, and a few Windows 3.11.  Theoretically,
NOTHING logs in as sa, except for a real live sa or the overnight
dbcc/backup scripts - these are not the culprit.  I have my suspicions
about Windows 3.11 clients as they cannot identify themselves as to
host.  Since it never happened until about 6 months ago, I suspect
some badly behaved application terminating in some manner so bizarre
that Sybase on the one hand can lose all information about the connection
and yet at the same time not understand the connection is dead for
whatever reason.

Does any of this sound familiar to anyone?  In the end, this kills
us when enough accumulate that we have no free file descriptors (spids)
to connect to, and applications start failing.

--
-----

                http://www.***.com/ ~ro/ro.html



Sat, 04 Oct 1997 03:00:00 GMT
 weird sa/master sysprocesses without host info


|>
|> This is one of the stranger things I've seen in 7 years of
|> Sybase administration.
|>
|> A few months back we started getting these spid's{*filter*} around
|> one of our servers (the busiest one) with the suid identified
|> as sa and the database as master.  Sysprocesses shows no information
|> whatsoever as to a hostname, program_name, host process id.
|>
|> These tend to accumulate.
|>
|> Server is 4.9.1 running on Sparc 10 SunOS 4.3.  Clients are
|> SunOS 4.3, NT Workstation 3.5, and a few Windows 3.11.  Theoretically,
|> NOTHING logs in as sa, except for a real live sa or the overnight
|> dbcc/backup scripts - these are not the culprit.  I have my suspicions
|> about Windows 3.11 clients as they cannot identify themselves as to
|> host.  Since it never happened until about 6 months ago, I suspect
|> some badly behaved application terminating in some manner so bizarre
|> that Sybase on the one hand can lose all information about the connection
|> and yet at the same time not understand the connection is dead for
|> whatever reason.

I suspect that the programs are terminating in a somewhat more mundane manner.
The problem is probably the Windows clients.  There is a known problem  where
the socket is not closed when Windows is rebooted using ctr-alt-del.  In previous
versions this would reboot the entire machine and close the socket, but in recent
versions this merely restarts Windows and does not clean up the sockets.

SQL Server relies on the network to inform it when a client terminates without
sending an explicit disconnect.  TCP does this through the keepidle/keepalive
utility.  Normally, when a client dies, the client-side OS closes the socket and
eventually the network sends a keepidle packet to the idle socket, determines
that it is closed, and closes the server-side socket, which closes the user
connection.  Unfortunately, since the PC side socket is staying open, keepalive
is reporting that the connection is still good, so the connection is staying open.

At the moment, there is no easy solution.  If you have users in the habit of
quiting their client sessions with a ctr-alt-del salute, you must convince them
to stop.  The only way to clear these connections is to cycle the server, or to
turn off the PCs and wait for keepidle to close the connection.  The default
keepidle interval is 2 hours, this may be configurable (check the SA Guide
Supplement for your platform).
--
---------------------------------------------------------------------

| Sybase Technical Support                                    __|
| 6475 Christie Avenue                                       |__
| Emeryville, CA 94608 USA                                      |___
| fax: (510)-922-3911        dberror 155 - "You can't do that"      |
#####################################################################



Sun, 05 Oct 1997 03:00:00 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. sa without sa privileges???

2. Host disappears from sysprocesses

3. program name and host name in sysprocesses table

4. master..sysprocesses.cpu???????

5. HELP: master..sysprocesses

6. Can a trigger be placed on master.sysprocesses?

7. Sysprocesses Table from Master DB!!!

8. Trigger on master.dbo.sysprocesses

9. interpreting master..sysprocesses

10. Ocasional missing Hostname i master..sysprocesses

11. strange query on master sysprocesses table

12. SELECT FROM master.dbo.sysprocesses


 
Powered by phpBB® Forum Software