Bug in Tiger check_listening_procs?
If I have found a bug then I will file a bug report.
My knowledge is imperfect. I thought I would check here first
before filing.
I am getting a report from tiger that squid is listening UDP on a high
port. This is not the peer cache listener as I have disabled that
with the -u0 squid command line option.
`lsof -nPi | grep squid` gives:
squid 19509 root5u IPv4 2036491 UDP *:32814
squid 19509 root 12u IPv4 2036495 TCP 127.0.0.1:3128 (LISTEN)
My understanding is that this UDP port is used by squid for its DNS
client. I do not understand why squid would want to bind to a port
for this. The port number changes when I restart squid.
Tiger reports this as listening on port 32814, which I do not think
is correct.
If lose is found on the system
/usr/lib/tiger/systems/Linux/2/check_listeningprocs uses the
command:
$LSOF -nPi | $GREP IPv | $GREP -v \- | $AWK '{printf(%s %s %s
%s\n, $1, $3, $7, $8)}' | $SORT | $UNIQ |
It seems that it should `grep LISTEN` as well.
Comments?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug in Tiger check_listening_procs?
On Sun, Mar 30, 2003 at 10:55:42AM -0800, Michael West wrote:
If I have found a bug then I will file a bug report.
My knowledge is imperfect. I thought I would check here first
before filing.
I am getting a report from tiger that squid is listening UDP on a high
port. This is not the peer cache listener as I have disabled that
with the -u0 squid command line option.
`lsof -nPi | grep squid` gives:
squid 19509 root5u IPv4 2036491 UDP *:32814
squid 19509 root 12u IPv4 2036495 TCP 127.0.0.1:3128 (LISTEN)
My understanding is that this UDP port is used by squid for its DNS
client. I do not understand why squid would want to bind to a port
for this. The port number changes when I restart squid.
Yes, that sounds right. Squid binds to a port for it's DNS resolver
simply because it expects to do so much DNS resolving that it's faster
to just fire the requests off and have an already-existing place for
them to arrive back at.
Tiger reports this as listening on port 32814, which I do not think
is correct.
That's what it's doing. Although it (hopefully) drops unsolicited
packets, it may not.
If lose is found on the system
/usr/lib/tiger/systems/Linux/2/check_listeningprocs uses the
command:
$LSOF -nPi | $GREP IPv | $GREP -v \- | $AWK '{printf(%s %s %s
%s\n, $1, $3, $7, $8)}' | $SORT | $UNIQ |
It seems that it should `grep LISTEN` as well.
Comments?
I would guess that only TCP sockets get 'LISTEN' but I don't
know the output of lsof to confirm this.
--
---
Paul TBBle Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
pgp0.pgp
Description: PGP signature
Bug in Tiger check_listening_procs?
If I have found a bug then I will file a bug report.
My knowledge is imperfect. I thought I would check here first
before filing.
I am getting a report from tiger that squid is listening UDP on a high
port. This is not the peer cache listener as I have disabled that
with the -u0 squid command line option.
`lsof -nPi | grep squid` gives:
squid 19509 root5u IPv4 2036491 UDP *:32814
squid 19509 root 12u IPv4 2036495 TCP 127.0.0.1:3128
(LISTEN)
My understanding is that this UDP port is used by squid for its DNS
client. I do not understand why squid would want to bind to a port
for this. The port number changes when I restart squid.
Tiger reports this as listening on port 32814, which I do not think
is correct.
If lose is found on the system
/usr/lib/tiger/systems/Linux/2/check_listeningprocs uses the
command:
$LSOF -nPi | $GREP IPv | $GREP -v \- | $AWK '{printf(%s %s %s
%s\n, $1, $3, $7, $8)}' | $SORT | $UNIQ |
It seems that it should `grep LISTEN` as well.
Comments?
Re: Bug in Tiger check_listening_procs?
On Sun, Mar 30, 2003 at 10:55:42AM -0800, Michael West wrote:
If I have found a bug then I will file a bug report.
My knowledge is imperfect. I thought I would check here first
before filing.
I am getting a report from tiger that squid is listening UDP on a high
port. This is not the peer cache listener as I have disabled that
with the -u0 squid command line option.
`lsof -nPi | grep squid` gives:
squid 19509 root5u IPv4 2036491 UDP *:32814
squid 19509 root 12u IPv4 2036495 TCP 127.0.0.1:3128
(LISTEN)
My understanding is that this UDP port is used by squid for its DNS
client. I do not understand why squid would want to bind to a port
for this. The port number changes when I restart squid.
Yes, that sounds right. Squid binds to a port for it's DNS resolver
simply because it expects to do so much DNS resolving that it's faster
to just fire the requests off and have an already-existing place for
them to arrive back at.
Tiger reports this as listening on port 32814, which I do not think
is correct.
That's what it's doing. Although it (hopefully) drops unsolicited
packets, it may not.
If lose is found on the system
/usr/lib/tiger/systems/Linux/2/check_listeningprocs uses the
command:
$LSOF -nPi | $GREP IPv | $GREP -v \- | $AWK '{printf(%s %s %s
%s\n, $1, $3, $7, $8)}' | $SORT | $UNIQ |
It seems that it should `grep LISTEN` as well.
Comments?
I would guess that only TCP sockets get 'LISTEN' but I don't
know the output of lsof to confirm this.
--
---
Paul TBBle Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
pgp6KOHFlywos.pgp
Description: PGP signature
