Laurel Fan wrote:
> Tried strings-ing it? anything interesting there?
here's some strings /tmp/ns stuff
beginning:
24.113.101.63
63.192.202.250
socket
bind
recvfrom
%s %s %s
aIf3YWfOhw.V.
PONG
*HELLO*
./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz$
UFC-crypt, patchlevel 1e, @(#)patchlevel.h
1.13 9/10/96
%s%s%s
<snip>
lots of things about gconv (/usr/lib/gconv),
<snip>
days of the week, months of the year, alert, backspace, newline,
vertical-tab, form-feed, carriage-return, space, exclamation-mark,
quotation-mark, <more similar special keys/characters>
<snip>
POSIX
messages
/usr/share/locale
<snip>
several errors like "wrong medium type", "remote I/O error", "is a named
type file", "network is down", "cannot assign requested address",
"address already in use", "address family not supported by protocol"
Success
0000000000000000
mention of: mbrtowc.c, wcrtomb.c, wcsrtombs.c, /proc/self/exe
find library=
cannot open shared object file
/etc/ld.so.cache
search cache=
ld.so-1.7.0
several elf errors
mention of: dynamic-link.h, dl-deps.c, dl-version.c, dl-runtime.c
and then a /dev/null near the end
24.113.101.63 traceroutes to...
15 cr354685-a.crdva1.bc.wave.home.com (24.113.101.63)
63.192.202.250 to...
argh it won't trace... stops at 10
but 63.192.1.1 traces to
9 adsl-63-192-1-1.dsl.snfc21.pacbell.net (63.192.1.1)
and 63.192.202.1 traces to
9 adsl-63-192-202-1.dsl.snfc21.pacbell.net (63.192.202.1)
so... it is likely adsl-63-192-202-250.dsl.snfc21.pacbell.net
(not that that may mean anything, but IPs are the first thing that came
to mind there...)
> When was that ns thing get put there? When did it start getting run by
> cron? When did it start erroring.
see below
> I don't think it's necessarily bind/named. There is a function called
> bind which binds a socket to an address, and it looks like it's
> erroring since its trying to bind an address aready in use. generally,
> when I write a program, i put the function name in the error message
> rather than the executable name, since I assume that you know what
> program you're running.
ahhh (light bulb goes on)
I understand a leetle better now. Shouldn't have listened to hubby when
he told me I was man-ing the wrong bind ;o)
> For a temporary fix, you can probably mv or rm the /tmp/ns an cron
> file.. and kill it if any is running. What I would try is playing with
> /tmp/ns to see what it does (strings, strace, looking at who put it
> there and when, etc). Personally, i'd be pretty suspicious of it,
> especially if i had no idea how it got there, though running it one more
> time probably wouldn't hurt if it's already been run 12,000 times...
i do have NO idea how it got there... but it was root created
(apparently)..
it was created on the 3rd (i was off by a day in earlier estimation),
which is when the errors started:
[root@ghettoBOX run]# ls -l /tmp/ns
-rwxr-xr-x 1 root root 305688 Nov 3 17:34 /tmp/ns*
same with /tmp/cron:
[root@ghettoBOX run]# ls -l /tmp/cron
-rw-r--r-- 1 root root 24 Nov 3 17:34 /tmp/cron
> You could try finding the real pid for sendmail with ps, then either HUP
> it (and fix its pidfile) or kill and restart it.
tried looking in ps aux and there is no sendmail there :o)
i believe i will nix or move the /tmp/ns and /tmp/cron files... i have
no idea what they are supposed to do, but i do not trust them
-nicole
************
[EMAIL PROTECTED] http://www.linuxchix.org
