From: Tilman Schmidt on
trey.chastain(a)yahoo.com schrieb:
> I ran '/etc/init.d/sendmail stop' and received no output.

Ok.

> typing netstat -an -f inet -P tcp gives me 2 processes listening on *.25

So whatever is squatting your machine's port 25 hasn't been found
by the /etc/init.d/sendmail script.

> typing netstat -an | grep \.25 gives me the same 3 process as before
> (no change)

The netstat command doesn't list processes, it lists network sockets.
It's not unheard of for a single process to have several sockets open.

> attempting to stop sendmail multiple times doesn't seem to change
> anything and I still receive no output.

That was to be expected.

> running ps ax just makes it show me the usage (there is no x
> option).

Hrmph. I thought I would be on the safe side with the old BSD-style
ps options, but it looks like Solaris doesn't accept those.
(Perhaps I should defer this case to people who actually have a
Solaris system in front of them.)

> ps -e (which lists information about every process, this is how I
> found sendmail) shows:
> PID TTY TIME CMD
[...]
> <b>4791 ? 0:03 sendmail</b>

Ah, there it is. I guess you inserted the "< b >" and "< / b >"
yourself.

> I realize 90% of that information is probably useless but it only took
> a short time to get it and if it helps solve my problem it was well
> worth it. I couldn't find any other ps commands that might be useful
> in this situation. Thanks for the advice, I hope this helps.

That's quite ok. A possibly interesting ps option would be the one
to display the complete command line of the process. Your ps command
may or may not do that if you pass it the -f option. You could try
"ps -ef" next time and see what it does.

For this round, however, whe know there is a sendmail process and
this is the prime candidate in our search for the squatter of your
port 25. Try killing it with the command "kill 4791" and check with
the netstat command you already know to see whether that frees the
port. If so, problem solved, and it only remains for you to find out
how that process got started in the first place. If not, there's
something odd going on on your server and you should perhaps start
looking for unwanted guests.

HTH
T.

--
Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...
From: Bill Cole on
In article <pan.2008.07.08.01.26.11.166823(a)gmail.com>,
AGT <usenetpersongerryt(a)gmail.com> wrote:

> Why is it connecting to mailhost? Is there one?

The traditional default Sun sendmail config is to use a smarthost for
everything, using the name 'mailhost' for it. You can find Solaris
admins who insist that this is a magic name, since adding an entry for
mailhost in /etc/hosts pointing to a working SMTP relay is the simplest
approach to making a Solaris machine pass mail outbound.

> What the heck shell are you using anyway??
> $ exec bash
> And try again

FWIW, the default Solaris shell is /bin/sh and is a direct descendant of
the original Bourne shell.

More to the point, it looks like the core problem in this case is a
mismatched config and binary. For all of Sun's many sins in regards to
sendmail, shipping a sendmail.cf that is many years and 22 major revs
out of date (8.11.6) and appears to not be specific to the Sun variation
of sendmail with a reasonably modern (8.13.7+Sun) binary is not the sort
of thing they do.

My guess: someone put a local build of sendmail on that machine at some
point without removing the Sun packages first, and at some later point
someone installed the full Sun "Recommended and Security" patch cluster,
which includes patches for the Sun sendmail packages. Since the package
database said the sendmail packages were still present, the patches went
right in and blasted away the local binary and maybe other random bits
and pieces. Tweaking this sort of damage into a working and serviceable
system is not feasible.

The fix for this sort of situation has to start with a decision about
whether to run Sun's version of sendmail or not and a Solaris-aware
implementation of that decision.

--
Now where did I hide that website...
First  |  Prev  | 
Pages: 1 2
Prev: confHELO_NAME
Next: sendmail log question?