Unix domain socket leak in 6-STABLE
Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Cheers, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
Ulrich Spoerlein wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Can you perhaps isolate the bug / give more information on it? I'm asking because I'm currently using an application with unix domain sockets in production wich handles lots of connects/disconnects per second and it doesn't seem to show leakage. signature.asc Description: OpenPGP digital signature
Re: Unix domain socket leak in 6-STABLE
On Wed, Jun 13, 2007 at 04:22:45PM +0200, Ulrich Spoerlein wrote: > Hi, > > as you are aware, there is a unix domain socket leak in 6-STABLE, > which AFAIK is not yet fully fixed. > > I wanted to ask about the status or some possible fixes, as I know a > way to reproduce the problem in a matter of minutes. > > We are running Cyrus and Postfix with the user DB in OpenLDAP. When > using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for > both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd > quickly runs out of filedescriptors as it is not closing any unix > sockets (judging by ever increasing lsof output). > > Using TCP sockets is just fine. If there are patches I could try, > don't hesitate to send them to me. Might be a red herring, but worth mentioning as a possibility: I've seen this kind of problem with domain sockets (at least on Linux with a multi-use tool called busybox) where on error conditions the code never bothered to close the existing socket it opened, thus resulting in leaks/resource exhaustion over time. The code later got fixed, but a pretty nasty bug especially when the program is used in a lot of embedded products... In regards to FreeBSD, I remember reading some mails from Robert Watson last month in regards to UNIX domain socket code changes: http://monkey.org/freebsd/archive/freebsd-stable/200705/msg00200.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
On Wed, 13 Jun 2007 16:22:45 +0200, Ulrich Spoerlein <[EMAIL PROTECTED]> wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Shouldn't slapd close its unix socket? Or am I misreading this. Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Cheers, Uli Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re Unix domain socket leak in 6-STABLE
On 6/13/07, Ivan Voras <[EMAIL PROTECTED]> wrote:
Can you perhaps isolate the bug / give more information on it? I'm
asking because I'm currently using an application with unix domain
sockets in production wich handles lots of connects/disconnects per
second and it doesn't seem to show leakage.
Ok, I'm not exactly sure what I should do. First of all, there are two
LDAP consumers: postfix and cyrus-saslauthd. A fairly common setup, I
suppose.
If I bombard this setup with hundreds of mails, cyrus is at one point
unable to process the mails further, stating that:
Jun 13 18:27:22 misctest1 lmtpunix[47460]: IOERROR: opening
/data/cyrus/spool/user/ulrspoe/cyrus.cache: Too many open files
The error is misleading, though, as it is not cyrus that is out of
file descriptors, but rather OpenLDAP. Restarting slapd will make
cyrus work again.
I logged the lsof output during the mail bomb and the slapd-lines are
continually rising:
misctest1# while :; do echo -n `date` " "; lsof 2>/dev/null | awk '$1
~ /imapd/{imapd+=1} $1 ~ /slapd/{slapd+=1} $3 ~ /postfix/{pf+=1}
END{print imapd, pf, slapd}'; sleep 60;done
Wed Jun 13 18:21:55 CEST 2007 1378 71 272
Wed Jun 13 18:22:57 CEST 2007 1378 71 272
Wed Jun 13 18:23:58 CEST 2007 1378 216 316
Wed Jun 13 18:24:59 CEST 2007 1378 321 644
Wed Jun 13 18:26:01 CEST 2007 1378 333 1132
Wed Jun 13 18:27:02 CEST 2007 1378 329 1804
Wed Jun 13 18:28:04 CEST 2007 1378 417 2280
The third column never goes down significantly. I have the setup now
sitting at 2k open files for the slapd process and will wait until
tomorrow, if the count ever decreases again.
Changing from
ldapi://%2fvar%2frun%2fopenldap%2fldapi/ to ldap://127.0.0.1/ "fixes"
the problem. It might be a genuine problem in OpenLDAP, though. We are
using openldap-server-2.3.34_1
Cheers,
Uli
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, June 13, 2007 09:17:36 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > I've seen this kind of problem with domain sockets (at least on Linux > with a multi-use tool called busybox) where on error conditions the > code never bothered to close the existing socket it opened, thus > resulting in leaks/resource exhaustion over time. The code later got > fixed, but a pretty nasty bug especially when the program is used in > a lot of embedded products... > > In regards to FreeBSD, I remember reading some mails from Robert Watson > last month in regards to UNIX domain socket code changes: > > http://monkey.org/freebsd/archive/freebsd-stable/200705/msg00200.html 'k, just to ring in here ... I can definitely attest to there being a leak here, as it was me that was originally burned by it ... in my case, I eventually was able to isolate which VPS/jail was causing it and haven't run it since, but was never able to determine exactly what was causing it, since there wasn't really anything unusual running in that jail :( But ... based on the discussions that were had at the time, it was my understanding that if all applications were shut down on the server (to the bare minimal), eventually the kernel GC should clean up all residual sockets ... when I did this (shut down all applications but the very bare minimum) and waited for 10+ minutes, socket usage never drop'd below about 4k sockets in use, or something like that ... Unlike Ulrich, I wasn't running LDAP at the time, so that wasn't the cause for me ... I could easily enough restart that jail if there was some more useful information I could get from it, but the thread kinda dwindled off over time, and rebooting a server ever 3 days was getting a wee bit annoying to my clients :) But, if someone has something they'd like me to do to provide more info, I'm willing to do it (short of anything that requires DDB / console access ... that server is remote) ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGcC0y4QvfyHIvDvMRApuZAJ9xKfa2/LqkcMkFEr4vrtnLt3ObcQCg43hs 7QX1hYskbQh/L8XJn1r1/Ts= =xKdx -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
Marc G. Fournier wrote: > 'k, just to ring in here ... I can definitely attest to there being a leak > here, as it was me that was originally burned by it ... in my case, I > eventually was able to isolate which VPS/jail was causing it and haven't run > it > since, but was never able to determine exactly what was causing it, since > there > wasn't really anything unusual running in that jail :( > > But ... based on the discussions that were had at the time, it was my > understanding that if all applications were shut down on the server (to the > bare minimal), eventually the kernel GC should clean up all residual sockets > ... when I did this (shut down all applications but the very bare minimum) > and > waited for 10+ minutes, socket usage never drop'd below about 4k sockets in > use, or something like that ... Hi Marc, was your leak a "kernel leak" or a "user leak" (if it actually makes a difference). Because I'm only hitting the problem within the slapd process itself. Restart it, every thing is good again. Other applications are also no affected. I think what's happening to me, is that slapd keeps unix domain sockets lingering too long. When blasting mails through the system, all those tiny ldap lookups then lead to slapd reaching it's process limit. I wonder though: maxfilesperproc is roughly 12k, but lsof needs to only count 2.5k lines of slapd output when the limit is hit. Is there a better way to check, how much fds/resources are open by a certain process? When using TCP sockets, the number of open files hardly changes. Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
On Wed, Jun 13, 2007 at 08:15:56PM +0200, Ulrich Spoerlein wrote: > I wonder though: maxfilesperproc is roughly 12k, but lsof needs to only > count 2.5k lines of slapd output when the limit is hit. Is there > a better way to check, how much fds/resources are open by a certain process? sockstat is what you're looking for. Also, do not forget about limits(1). If the sockets aren't being closed (in any condition; after completion or after error), there's going to be a leak until the daemon is restarted. I wouldn't be surprised if this is what's happening, based on previous experience I've had with slapd during my day job. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
On 6/13/07, Ulrich Spoerlein <[EMAIL PROTECTED]> wrote: Hi, as you are aware, there is a unix domain socket leak in 6-STABLE, which AFAIK is not yet fully fixed. I wanted to ask about the status or some possible fixes, as I know a way to reproduce the problem in a matter of minutes. We are running Cyrus and Postfix with the user DB in OpenLDAP. When using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd quickly runs out of filedescriptors as it is not closing any unix sockets (judging by ever increasing lsof output). Using TCP sockets is just fine. If there are patches I could try, don't hesitate to send them to me. Ohhh !! I had exactly the same problem last night. After change the line of /usr/local/etc/nss_ldap.conf from uri ldap://127.0.0.1/ to uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ The open sockets off this machine started to increase until reach maxfiles limit and show messages like this: kernel: kern.maxfiles limit exceeded by uid 65534, please see tuning(7). and slapd stopped to accept new connections. During the day (production hours) the number off connections (using TCP sockets) to OpenLDAP range from 16 to 45. Last night after change the type connection to Unix Domain Socket the number of connections raised rapidly to about 4000. I get this numbers using sockstat -c command. This machine is our Samba PDC, running 6.2-STABLE compile in Apr 5 13:33:50 using samba-3.0.24,1, nss_ldap-1.255, openldap-server-2.3.34_1 I can provide more information if need. Any Advises/Patches ? Best Regards, Alexandre Biancalana ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
* Alexandre Biancalana <[EMAIL PROTECTED]> [070613 12:40] wrote: > On 6/13/07, Ulrich Spoerlein <[EMAIL PROTECTED]> wrote: > > > >Hi, > > > >as you are aware, there is a unix domain socket leak in 6-STABLE, > >which AFAIK is not yet fully fixed. > > > >I wanted to ask about the status or some possible fixes, as I know a > >way to reproduce the problem in a matter of minutes. > > > >We are running Cyrus and Postfix with the user DB in OpenLDAP. When > >using ldapi://%2fvar%2frun%2fopenldap%2fldapi/ as a connection URL for > >both Postfix' user lookup and cyrus' user lookup (via nss_ldap). slapd > >quickly runs out of filedescriptors as it is not closing any unix > >sockets (judging by ever increasing lsof output). > > > >Using TCP sockets is just fine. If there are patches I could try, > >don't hesitate to send them to me. > > > > Ohhh !! I had exactly the same problem last night. > > After change the line of /usr/local/etc/nss_ldap.conf from > > uri ldap://127.0.0.1/ > > to > > uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ > > The open sockets off this machine started to increase until reach maxfiles > limit and show messages like this: > > kernel: kern.maxfiles limit exceeded by uid 65534, please see tuning(7). > > and slapd stopped to accept new connections. > > During the day (production hours) the number off connections (using TCP > sockets) to OpenLDAP range from 16 to 45. Last night after change the type > connection to Unix Domain Socket the number of connections raised rapidly to > about 4000. I get this numbers using sockstat -c command. > > This machine is our Samba PDC, running 6.2-STABLE compile in Apr 5 13:33:50 > using samba-3.0.24,1, nss_ldap-1.255, openldap-server-2.3.34_1 > > I can provide more information if need. > > Any Advises/Patches ? I would advise running "truss" or ktrace against the process to see if it's actually attempting to close the descriptor. this would explain if the leak is in the application, or maybe libc/kernel. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
On 6/13/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote: I would advise running "truss" or ktrace against the process to see if it's actually attempting to close the descriptor. this would explain if the leak is in the application, or maybe libc/kernel. -- - Alfred Perlstein Hi ! I change nss_ldap.conf again to access OpenLDAP via unix domain socket. Here is the connection counter before the change: Wed Jun 13 22:35:55 BRT 2007 unix sockets: 99 tcp sockets: 12 Here is the connection counter rigth before change connection method back to TCP socket: Wed Jun 13 22:56:01 BRT 2007 unix sockets: 2902 tcp sockets: 13 Follow the link to the 500k lines kdump file from a ktrace of an smbd process that leaked more than 1000 unix domain sockets connections during this time. http://www.seudns.net/~ale/smbd.kdump.bz2 ps: I removed some lines from the file that shows socket read returns, because they showed usernames e other informations that I don't want to expose. Regards, Alexandre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, June 13, 2007 20:15:56 +0200 Ulrich Spoerlein <[EMAIL PROTECTED]> wrote: > was your leak a "kernel leak" or a "user leak" (if it actually makes a > difference). I don't know ... it was caused by an application, but nothing was freed up after the application was stop'd ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGcWes4QvfyHIvDvMRAnaVAJ4pfQ69GvcfXObQ37yMlHG61Foz4wCcClFp p2TKa/KvLdgkKv9XCbA5hok= =d3WG -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
On 6/14/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote: I don't know ... it was caused by an application, but nothing was freed up after the application was stop'd ... In my case the sockets are closed only if I stop the samba processes. When I just changed the connection mode from Unix Socket to TCP on nss_ldap.conf, the connections remain opened. I think this could be a problem with nss_ldap (in the way of the connections are handled ?) because samba is accessing OpenLDAP directly via TCP, the access via Unix Sockets is only done by Samba throughnss_ldap. I trying to simulate this error on another machine. I will write some scripts/program that connect to OpenLDAP socket directly and via nss_ldap and post the results. Any more hints ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, June 14, 2007 14:03:27 -0300 Alexandre Biancalana <[EMAIL PROTECTED]> wrote: > On 6/14/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote: > >> I don't know ... it was caused by an application, but nothing was freed up >> after the application was stop'd ... > > > In my case the sockets are closed only if I stop the samba processes. When I > just changed the connection mode from Unix Socket to TCP on nss_ldap.conf, > the connections remain opened. I think this could be a problem with nss_ldap > (in the way of the connections are handled ?) because samba is accessing > OpenLDAP directly via TCP, the access via Unix Sockets is only done by Samba > throughnss_ldap. > > I trying to simulate this error on another machine. I will write some > scripts/program that connect to OpenLDAP socket directly and via nss_ldap > and post the results. > > Any more hints ? Hrmm .. how about nss in general? the one VPS that I killed off was using nss-mysql for passwd/group and shadow ... its definitely not something that is normally done here, and about the only thing I can think of that is 'unusual' about that specific VPS, in my case ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD4DBQFGcZL54QvfyHIvDvMRAgbBAJ4zbygUUNdl6kKEp+sAPW0vLgJsvwCWP768 Ulzq5eM+ygPOM+A243NTsg== =EuC7 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unix domain socket leak in 6-STABLE
On 6/14/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, June 14, 2007 14:03:27 -0300 Alexandre Biancalana
<[EMAIL PROTECTED]> wrote:
> On 6/14/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
>
>> I don't know ... it was caused by an application, but nothing was freed
up
>> after the application was stop'd ...
>
>
> In my case the sockets are closed only if I stop the samba processes.
When I
> just changed the connection mode from Unix Socket to TCP on
nss_ldap.conf,
> the connections remain opened. I think this could be a problem with
nss_ldap
> (in the way of the connections are handled ?) because samba is accessing
> OpenLDAP directly via TCP, the access via Unix Sockets is only done by
Samba
> throughnss_ldap.
>
> I trying to simulate this error on another machine. I will write some
> scripts/program that connect to OpenLDAP socket directly and via
nss_ldap
> and post the results.
>
> Any more hints ?
Hrmm .. how about nss in general? the one VPS that I killed off was using
nss-mysql for passwd/group and shadow ... its definitely not something
that is
normally done here, and about the only thing I can think of that is
'unusual'
about that specific VPS, in my case ...
H maybe... I don't know nss-mysql (I didn't ever know about your
existence. hahaha) What's the connection method used to access MySQL
database ? You can read the rest of my message and try a similar test..
How I said. here is the test:
I write the following perl script:
#!/usr/bin/perl
$counter = 0;
@users = ('user1', 'user2', 'user3');
while ( $counter <= 4 ) {
my $idx = int(rand($#users));
my @data = getpwnam($users[$idx]);
print join(' ', @data) . "\n";
$counter++;
}
sleep(50);
After run the script I have:
AleStation:/usr/home/ale $ sockstat -uc
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN
ADDRESS
root xterm 1528 3 stream -> /tmp/.X11-unix/X0
root xterm 1464 3 stream -> /tmp/.X11-unix/X0
ale nedit 1436 3 stream -> /tmp/.X11-unix/X0
ale xmms 1404 3 stream -> /tmp/.X11-unix/X0
ale gconfd-2 1331 4 dgram -> ??
ale gconfd-2 1331 12 stream
/var/tmp/orbit-ale/linc-533-0-37a529d2e9123
ale gconfd-2 1331 14 stream ->
/var/tmp/orbit-ale/linc-52b-0-249abddc2887e
ale dbus-daemo 1329 4 stream -> /var/run/openldap/ldapi
ale dbus-daemo 1329 5 stream -> ??
ale dbus-daemo 1329 7 stream -> ??
ale dbus-daemo 1329 8 stream /var/tmp/dbus-luPSSzilmv
ale dbus-daemo 1329 10 stream -> /var/run/openldap/ldapi
ale dbus-launc 1328 3 stream -> /tmp/.X11-unix/X0
ale pidgin 1324 3 stream -> /tmp/.X11-unix/X0
ale pidgin 1324 5 stream -> /var/tmp/dbus-luPSSzilmv
ale firefox-bi 1323 3 stream -> /tmp/.X11-unix/X0
ale firefox-bi 1323 11 stream ->
/var/tmp/orbit-ale/linc-533-0-37a529d2e9123
ale firefox-bi 1323 19 stream
/var/tmp/orbit-ale/linc-52b-0-249abddc2887e
ale gkrellm1309 5 stream -> /tmp/.X11-unix/X0
ale wmaker 1306 3 stream -> /tmp/.X11-unix/X0
root Xorg 1301 10 stream /tmp/.X11-unix/X0
root Xorg 1301 11 stream /tmp/.X11-unix/X0
root Xorg 1301 12 stream /tmp/.X11-unix/X0
root Xorg 1301 13 stream /tmp/.X11-unix/X0
root Xorg 1301 14 stream /tmp/.X11-unix/X0
root Xorg 1301 15 stream /tmp/.X11-unix/X0
root Xorg 1301 16 stream /tmp/.X11-unix/X0
root Xorg 1301 17 stream /tmp/.X11-unix/X0
root Xorg 1301 18 stream /tmp/.X11-unix/X0
root Xorg 1301 19 stream /tmp/.X11-unix/X0
ale xinit 1300 3 stream -> /tmp/.X11-unix/X0
root login 1295 3 dgram -> ??
root login 1295 5 stream -> /var/run/openldap/ldapi
root natd 1294 4 dgram -> ??
_dhcpdhclient 1219 3 dgram -> ??
root dhclient 1195 3 dgram -> ??
root smbd 1044 4 dgram -> ??
root smbd 1044 18 stream ->
/var/db/samba/winbindd_privileged/pipe
root smbd 1044 22 stream -> /var/run/openldap/ldapi
root winbindd 954 3 dgram -> ??
root winbindd 954 15 stream -> ??
root winbindd 954 17 stream -> ??
root winbindd 954 19 stream /var/db/samba/winbindd_privileged/pipe
root winbindd 954 20 stream -> ??
root winbindd 953 3 dgram -> ??
root winbindd 953 15 stream -> ??
root winbindd 953 17 stream -> ??
root winbindd 953 19 stream /var/db/samba/winbindd_privileged/pipe
root winbindd 951 3 dgram -> ??
root winbindd 951 14 stream -> ??
root winbindd 925 3 dgram -> ??
root winbindd 925 15 stream -> ??
root winbindd 925 19 stream /var/db/samba/winbindd_privileged/pipe
root winbindd 925 20 stream -> ??
root winbindd 925 21 stream -> ??
root smbd 921 4 dgram -> ??
root smbd 921
