Very Computer

by **Marvi** » Wed, 08 Aug 2001 14:42:10

Hi !

Using netstat -a there can be seen all sockets currently made. Is there
any way to get PID of the process, who had opened (created, whatever)
specified socket ?

by **Marvi** » Wed, 08 Aug 2001 16:21:31

> > Hi !

> > Using netstat -a there can be seen all sockets currently made. Is there
> > any way to get PID of the process, who had opened (created, whatever)
> > specified socket ?

> Not from netstat. Use lsof available from the 'usual places'.

I would prefer not using any application which is not in Solaris inst.
package

by **Rich Andrew** » Wed, 08 Aug 2001 17:39:08

>> > Hi !

>> > Using netstat -a there can be seen all sockets currently made. Is
>> > there any way to get PID of the process, who had opened (created,
>> > whatever) specified socket ?

>> Not from netstat. Use lsof available from the 'usual places'.

> I would prefer not using any application which is not in Solaris inst.
> package

You must like crippling yourself. I don't know how anyone can survive
without 3rd party software on any OS.

rich

by **Marvi** » Wed, 08 Aug 2001 19:11:23

> >> > Hi !

> >> > Using netstat -a there can be seen all sockets currently made. Is
> >> > there any way to get PID of the process, who had opened (created,
> >> > whatever) specified socket ?

> >> Not from netstat. Use lsof available from the 'usual places'.

> > I would prefer not using any application which is not in Solaris inst.
> > package

> You must like crippling yourself. I don't know how anyone can survive
> without 3rd party software on any OS.

> rich

I have over 30 Enterprises, and coming even more and more each month,
and would really go crazy installing all 3rd party application to all of
the servers, that's why I first ask for pure Solaris solution. Perhaps
some /usr/proc/bin/p... util would give what I want....
Installing 3rd party would be the last solution.

by **Mike_Ciccarell** » Wed, 08 Aug 2001 22:45:26

Quote:> I have over 30 Enterprises, and coming even more and more each month,
> and would really go crazy installing all 3rd party application to all of
> the servers, that's why I first ask for pure Solaris solution. Perhaps
> some /usr/proc/bin/p... util would give what I want....
> Installing 3rd party would be the last solution.

If you're running similar hardware and OS levels than "installing" on
one machine might be a solution then sharing via nfs to others when you
have a problem would work.. Some software will be harder to get to work
because of libs, but there are ways around that.. Just a thought.. and
yes, I would recommend lsof and fuser for checking on apps

mike

by **Mathew Kirsc** » Wed, 08 Aug 2001 23:59:33

> I have over 30 Enterprises, and coming even more and more each month,
> and would really go crazy installing all 3rd party application to all of
> the servers, that's why I first ask for pure Solaris solution. Perhaps
> some /usr/proc/bin/p... util would give what I want....
> Installing 3rd party would be the last solution.

How much you have left to learn, young grasshopper...

Only *s would manually install a 3rd party utility on 30+ hosts.
That's why they created rdist and rsync. rsync is the new kid on the block,
and probably the future of remote file distribution.

by **Marvi** » Thu, 09 Aug 2001 18:58:30

> > I have over 30 Enterprises, and coming even more and more each month,
> > and would really go crazy installing all 3rd party application to all of
> > the servers, that's why I first ask for pure Solaris solution. Perhaps
> > some /usr/proc/bin/p... util would give what I want....
> > Installing 3rd party would be the last solution.

> How much you have left to learn, young grasshopper...

> Only *s would manually install a 3rd party utility on 30+ hosts.
> That's why they created rdist and rsync. rsync is the new kid on the block,
> and probably the future of remote file distribution.

I know there is thousands of software to help you investigating things.
But from my practice, it is wise to know how to do something manually,
and after that use appropriate software to help you. After all, you
increase your knowledge how things works, not to left them just to work.
Installing 3rd party software no matter which way (manually, rcp, rdist
etc..) would be a bad solution. I would prefer then exported partition
with such software via NFS, but some software needs special libraries to
run, and in that case, mounted partition would not help either.

by **Mathew Kirsc** » Thu, 09 Aug 2001 22:47:46

> I know there is thousands of software to help you investigating things.
> But from my practice, it is wise to know how to do something manually,
> and after that use appropriate software to help you. After all, you
> increase your knowledge how things works, not to left them just to work.

lsof wouldn't exist if there were a native tool, or some manual way to do what
it does. UNIX programmers aren't known for constantly reinventing the wheel,
and frankly I don't see the point of digging a hole with your fingernails when
there's a perfectly good shovel sitting there.

Quote:> Installing 3rd party software no matter which way (manually, rcp, rdist
> etc..) would be a bad solution. I would prefer then exported partition
> with such software via NFS, but some software needs special libraries to
> run, and in that case, mounted partition would not help either.

Put the special libraries on the same mounted partition as the tools, and
build the tools properly so they know where to look. What's so difficult about
that?

by **Steve Boyl** » Fri, 10 Aug 2001 00:13:04

The following will give you the connection between pids and sockets, it is
not
very nice but could scripted quite simply.

run /usr/sbin/crash

type in 'proc'

For each process in the list, type in 'user' followed by the process SLOT
number. This will give you a breakdown of the user address space of the
process, within which is a list of open files.
Now for each of those open files, type in 'file' followed by the address
listed above. This will give you some information on what type of file it
is.
Since we are interested in just sockets only files with a TYPE of SOCK are
for
us.

Now type in 'socket -l' followed by the address from the file command above
and you will get the details of this socket. In there you will find the
source
and destination ports.

btw, I use lsof.......

Cheers
Steve

*********************

*********************

by **Marvi** » Fri, 10 Aug 2001 14:35:46

> The following will give you the connection between pids and sockets, it is
> not
> very nice but could scripted quite simply.

> run /usr/sbin/crash

> type in 'proc'

> For each process in the list, type in 'user' followed by the process SLOT
> number. This will give you a breakdown of the user address space of the
> process, within which is a list of open files.
> Now for each of those open files, type in 'file' followed by the address
> listed above. This will give you some information on what type of file it
> is.
> Since we are interested in just sockets only files with a TYPE of SOCK are
> for
> us.

> Now type in 'socket -l' followed by the address from the file command above
> and you will get the details of this socket. In there you will find the
> source
> and destination ports.

> btw, I use lsof.......

> Cheers
> Steve

> *********************

> *********************

Thank you very much. 100% what I needed.

by **Marvi** » Fri, 10 Aug 2001 16:48:36

> > I know there is thousands of software to help you investigating things.
> > But from my practice, it is wise to know how to do something manually,
> > and after that use appropriate software to help you. After all, you
> > increase your knowledge how things works, not to left them just to work.

> lsof wouldn't exist if there were a native tool, or some manual way to do what
> it does. UNIX programmers aren't known for constantly reinventing the wheel,
> and frankly I don't see the point of digging a hole with your fingernails when
> there's a perfectly good shovel sitting there.

> > Installing 3rd party software no matter which way (manually, rcp, rdist
> > etc..) would be a bad solution. I would prefer then exported partition
> > with such software via NFS, but some software needs special libraries to
> > run, and in that case, mounted partition would not help either.

> Put the special libraries on the same mounted partition as the tools, and
> build the tools properly so they know where to look. What's so difficult about
> that?

It's just you don't have a clue what I want. Isnt satisfyable to extend
your knowledge knowing such things ? Or you prefer to be "I don't know,
but there is a program..." kind of guy ...

by **Mathew Kirsc** » Sat, 11 Aug 2001 23:36:22

> It's just you don't have a clue what I want. Isnt satisfyable to extend
> your knowledge knowing such things ? Or you prefer to be "I don't know,
> but there is a program..." kind of guy ...

You refuse to read what I'm writing.

lsof does something you CAN'T do with regular OS commands. Either you get the
information with lsof, or you don't get the information.

lsof comes with source code, if you want to know how it works.

by **George William Herbe** » Sun, 12 Aug 2001 07:25:40

>> > I know there is thousands of software to help you investigating things.
>> > But from my practice, it is wise to know how to do something manually,
>> > and after that use appropriate software to help you. After all, you
>> > increase your knowledge how things works, not to left them just to work.

>> lsof wouldn't exist if there were a native tool, or some manual way to do what
>> it does. UNIX programmers aren't known for constantly reinventing the wheel,
>> and frankly I don't see the point of digging a hole with your fingernails when
>> there's a perfectly good shovel sitting there.

>> > Installing 3rd party software no matter which way (manually, rcp, rdist
>> > etc..) would be a bad solution. I would prefer then exported partition
>> > with such software via NFS, but some software needs special libraries to
>> > run, and in that case, mounted partition would not help either.

>> Put the special libraries on the same mounted partition as the tools, and
>> build the tools properly so they know where to look. What's so difficult about
>> that?

>It's just you don't have a clue what I want. Isnt satisfyable to extend
>your knowledge knowing such things ? Or you prefer to be "I don't know,
>but there is a program..." kind of guy ...

There is no OS-bundled utility to do that. If you want to do
that, you'll have to go out and get lsof. If you flatly refuse
to install third party tools, you can't do that. Are you under
some mistaken impression that the OS must have every possible
feature bundled with it already?

There's a command called "fusers" which will tell you what processes
have a *file* open, but that doesn't extend to network connections.

-george william herbert

Very Computer

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID

Socket -> PID