Well, the problem was a malformed entry in the password file.
Thanks some input from Steven Ho from Sun for pointing me in the
right direction. He recommended running a program to check the entries
(enclosed below), however, this didn't show the corrupted entry.
What i ended up running was a System V program pwck which pointed
to the invalid entry.
This points out the dangers of running sendmail in remote mode.
With the remote mode I had numerous users, who were mistyping user
names, complaining about slow systems due to hung sendmail processes.
Further more, our accounting processes on one of our systems were
also getting hung.
----------------------------------------------------------------------
Mike Sullivan Bell Communications Research
mbs@bae.bellcore.com Phone: (908) 699-4856
444 Hoes Lane Room RRC-1E221
Piscataway, NJ 08854
::::::::::::::
NIS.PROBLEM/1
::::::::::::::
Return-Path: Ying.Ho@Corp.Sun.COM
Received: from flash.bellcore.com by bae.bae.bellcore.com (4.1/4.7)
id AA16327; Wed, 26 Aug 92 10:58:08 EDT
Received: from Sun.COM by flash.bellcore.com (5.65/1.34)
id AA09294; Wed, 26 Aug 92 10:58:06 -0400
Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA11211; Wed, 26 Aug 92 07:53:05 PDT
Received: from landsat.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound))
id AA08327; Wed, 26 Aug 92 07:52:56 PDT
Received: by landsat.Corp.Sun.COM (5.0/SMI-SVR4)
id AA01426; Wed, 26 Aug 92 14:56:23 GMT
Date: Wed, 26 Aug 92 14:56:23 GMT
From: Ying.Ho@Corp.Sun.COM (Steven Ho)
Return-Receipt-To: Ying.Ho@Corp.Sun.COM
Message-Id: <9208261456.AA01426@landsat.Corp.Sun.COM>
To: mbs@bae.bellcore.com
Subject: Re: help with an interesting NIS problem and sendmail
Cc: Ying.Ho@Corp.Sun.COM
Content-Length: 3080
Mike,
This is typical if a password entry is corrupted. You might have
six or eight fields for that particular entry.
Run the following test program, when it hangs the next password
entry is corrupted.
-------------------------------
/* Check if password file/map is corrupted. */
#include <stdio.h>
#include <pwd.h>
main()
{
register struct passwd *pw;
struct passwd *getpwent();
while ((pw = getpwent()) !=NULL) {
printf("The passwd entry is: %s %s\n", pw->pw_name, pw->pw_gecos);
}
exit(0);
}
-------------------------------
Hope this helps,
Steven Ho
yjho@corp.sun.com
415-336-3364
::::::::::::::
NIS.PROBLEM/2
::::::::::::::
Return-Path: Ying.Ho@Corp.Sun.COM
> From sun-managers-relay@ra.mcs.anl.gov Wed Aug 26 04:55 PDT 1992
> To: sun-managers@eecs.nwu.edu
> Subject: help with an interesting NIS problem and sendmail
> Cc: mbs@bae.bellcore.com
> From: Mike Sullivan <mbs@bae.bellcore.com>
>
>
> problem symptoms:
> the problem shows itself when I use the Remote option in a "subsidiary"
> client sendmail.cf file (i used the sun supplied copy in /usr/lib to
> avoid questions about what my sendmail.cf looks like).
> The problem is best boiled down to when one talks SMTP to one of
> the clients and specifies an unknown user the sendmail process goes
> into an infinity loop. This SMTP conversation can be simulated via
> the command mconnect.
>
>
> + here's a sample session:
> - the simplest way to mimick MH's behavior is to do the following
>
> > mconnect
> connecting to host localhost (127.0.0.1), port 25
> connection open
> 220 xxxxx.xxxxx.xxxxx.xxxx Sendmail 4.1/SMI-4.1 ready at Tue, 25 Aug 92 18:23:52 EDT
>
> vrfy nosuchuser
>
> - this is where it gets into an infinite loop and here's what's on the
> process queue:
>
> USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND
> root 18653 40.3 1.6 136 440 ? R 18:12 0:04 -From localhost: vrfy (sendmail)
>
> - a trace of the process reveals the following repeated calls:
> gettimeofday (0xf7ffdd60, 0) = 0
> getpid () = 18653
> sendto (7, "<38>Aug 25 18:13:57 sendmail[186".., 99, 0, 0x30478, 16) = 99
>
>
> + now when i repeat this scenario by making the password file local or
> by making the NIS server for this machine local, then the problem goes
> away.
>
> PROBLEM SUMMARY ....
>
> - obviously this is an NIS problem of some sort, but i don't know what
> to look for next. any ideas?
>
> - to temporarily get around the problem i installed a version of
> the client sendmail.cf that was posted to sun-managers about a week
> ago. this version does not have the remote option turned on so all
> look up's occur on the mail gateway avoiding this problem altogether.
>
>
> --------------------------------------------------------------------------------
> Mike Sullivan Bell Communications Research
> mbs@bae.bellcore.com Phone: (908) 699-4856
> 444 Hoes Lane Room RRC-1E221
> Piscataway, NJ 08854
>
::::::::::::::
NIS.PROBLEM/2
::::::::::::::
Return-Path: ramey@jello.csc.ti.com
Received: from flash.bellcore.com by bae.bae.bellcore.com (4.1/4.7)
id AA17679; Wed, 26 Aug 92 11:39:33 EDT
Received: from ti.com by flash.bellcore.com (5.65/1.34)
id AA12155; Wed, 26 Aug 92 11:39:31 -0400
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP
(5.59/LAI-3.2) id AA01985; Wed, 26 Aug 92 10:39:30 CDT
Received: from jello.csc.ti.com (jello) by tilde.csc.ti.com id AA12435; Wed, 26 Aug 1992 10:38:43 -0500
Received: by jello.csc.ti.com (4.1/SMI-4.1)
id AA00925; Wed, 26 Aug 92 10:38:42 CDT
Date: Wed, 26 Aug 92 10:38:42 CDT
From: ramey@jello.csc.ti.com (Joe Ramey)
Message-Id: <9208261538.AA00925@jello.csc.ti.com>
To: Mike Sullivan <mbs@bae.bellcore.com>
In-Reply-To: mbs@bae.bellcore.com's message of 25 Aug 92 22:29:52 GMT
Subject: help with an interesting NIS problem and sendmail
According to this recent posting from comp.mail.sendmail a while back,
OR mode is seriously broken and should not be used:
From: per@erix.ericsson.se (Per Hedeland)
Newsgroups: comp.mail.sendmail
Subject: Re: OR (remote mode)?
Date: 28 Jul 92 20:53:39 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Nntp-Posting-Host: super.eua.ericsson.se
In article <1992Jul28.155421.20972@newsgate.sps.mot.com>
embry@iam.unibe.ch (Mike Embry) writes:
>> Many people consider 'OR' a bad idea, and comment out that line.
>
>Could you elucidate or otherwise illuminate the reasons why?
Guess it's time for this list again... Btw, I personally think the
*idea* is bad mainly because it violates the layering principles of
sendmail - a normal sendmail doesn't know or care where the local mailer
puts the mail - but some mechanism to find out if (e.g.)
/var/spool/mail is NFS-mounted and if so from where might be a useful
thing... Like, say, if 'OR/var/spool/mail' had the effect of putting the
name of the exporting host, if any, into $R, to be used in normal .cf
rules. However, the *implementation* of OR is utter disaster! Anyway,
here goes...
Here is a list of the bugs/problems with Sun's braindead OR sendmail.cf
option that I've found to date:
1. If the connection between client and server sendmail is broken during
the DATA phase (i.e when the actual letter is transferred), the letter
is lost, without any information to user or Postmaster, the only trace
is a "SYSERR: net hang reading from..." type of message in syslog.
2. Anyone can fake sender addresses with sendmail -f.
3. Sendmail -t forgets to remove temp file (fixed post-4.0.3, I believe).
4. Sendmail -t called from emacs (actually whenever it can't do a
getlogin()) with a local recipient address will put the *recipient*
address in the From: line.
5. If a sendmail deamon is run (e.g. if you want to be kind enough to handle
the occasional mail mis-addressed to user@client rather than having it
sit in some queue for several days before being bounced), it will ignore
the OR option, and happily do local delivery causing /bin/mail to write
/var/spool/mail via NFS, or send directly to hosts in the YP map while
setting the sender address to user@client. In addition, the local
delivery is somehow half-baked, ignoring e.g. .forward files.
6. Since (in the normal non-deamon case) the sendmail.cf apart from OR is
essentially ignored, it isn't possible to do *any* host-specific
handling, e.g. splitting up mail to root depending on which client
generated it.
7. If the mailhost isn't reachable, each letter sent will cause the
corresponding sendmail process to sit in a loop doing repeated attempts
- apart from the load, this means that if the client is shut down or
rebooted before successful delivery, the mail is lost.
8. It doesn't work at all if /var/spool/mail is auto-mounted.
9. Sendmail -t will remove one empty line between header and body, with
the effect that initial body lines that have leading whitespace, or
that start with <word>:, are moved to the header.
10. Sendmail -t where the destination is a local alias will generate a
"User unknown" error message (although the letter will be delivered
correctly) - if PostmasterCopy is in effect, there will (of course)
be an additional "User unknown" for Postmaster.
11. If a letter without a terminating newline is sent (except when using
sendmail -t), it will not be transferred to the server, instead the
connection will time out, and the net result will be as for 1 above
(this is presumably the major case where those symptoms are observed).
I realize that 6 and 7 are consequences of intentional design decisions, and
that 5 might be considered operator error; I still consider them deficiencies.
I definitely recommend using one of the minimalist sendmail.cf's for this
purpose that has been floating around the net instead of the OR option. The
only inconveniences with this are that you have to actually spell out the
name of the mailhost, and that you have to make sure the client's queue is
checked - if you don't want to run a deamon (which I think is the best
solution - the load from this should be neglible), you can have sendmail -q
run from crontab e.g. hourly. On the other hand, you can use the same
sendmail.cf on non-Sun mail clients.
I have done just this, using essentially the version that Rich Salz sent out
on comp.mail.sendmail a while back (the smallest one I've seen so far:-),
and all of the problems went away.
--Per Hedeland
per@erix.ericsson.se or
per%erix.ericsson.se@sunic.sunet.se or
...uunet!erix.ericsson.se!per
------- End of forwarded message -------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:48 CDT