Re: bandwidth by user or process id

[Rob Hasselbaum <rob () hasselbaum net>]

On Wed, Oct 6, 2010 at 8:47 AM, Rob Hasselbaum <rob () hasselbaum net> wrote:

> On Tue, Oct 5, 2010 at 1:53 PM, Phil Vandry <vandry () tzone org> wrote:
>
> > On Mon, 4 Oct 2010 09:51:39 -0400 Rob Hasselbaum <rob () hasselbaum net>
> > wrote:
> > > Yes, it is possible (on Linux, anyway), but not extremely easy. You can
> > > correlate packet data to the kernel's network connection table and
> > network
> > > connections to inode values by reading "/proc/net/tcp*" and
> >
> > Isn't that unreliable? The connection might be short-lived and disappear
> > from /proc/net/{tc,ud}p* before you have a chance to find it.
> >
> > Since you are assuming Linux anyway, have you considered using iptables?
> >
> > If you don't have a huge number of users, you can create a rule like this
> > for each uid:
> >
> > iptables -I OUTPUT -m owner --uid-owner <foo> -j ACCEPT
> >
> > and then just monitor the packet & byte counters on these rules.
> Yes, that can happen and it's a good point. For my situation, it's not too
> relevant, though. Socket Sentry is intended to be a real-time bandwidth
> monitor (like "iftop"), so short-lived connections/processes are not very
> interesting. And I don't think it would go over well with my users if I
> started messing with their iptables configurations. ;-) Maybe that's a
> better solution for Patrick, though.
Actually, I take some of that back. (Haven't had my morning coffee yet.) For
TCP anyway, the connections stay in the table for a while after the last
payload. (Connection stays in TIME_WAIT state or similar.) So I do pick up
the short-lived ones. The more likely problem scenario is that I'll miss a
short-lived process. In those cases, Socket Sentry still reports the
traffic, but marks the process/user as unknown.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.