From owner-freebsd-questions Sat Feb 18 14:00:59 1995 Return-Path: questions-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA26790 for questions-outgoing; Sat, 18 Feb 1995 14:00:59 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA26783 for ; Sat, 18 Feb 1995 14:00:58 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA28027; Sat, 18 Feb 95 14:54:17 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502182154.AA28027@cs.weber.edu> Subject: Re: New sendmail in 0210SNAP? To: xiao@bnr.ca (bo) Date: Sat, 18 Feb 95 14:54:17 MST Cc: ats@g386bsd.first.gmd.de, tsbarry@bnr.ca, freebsd-questions@FreeBSD.org In-Reply-To: <"3465 Sat Feb 18 16:12:13 1995"@bnr.ca> from "bo" at Feb 18, 95 04:12:00 pm X-Mailer: ELM [version 2.4dev PL52] Sender: questions-owner@FreeBSD.org Precedence: bulk > >No, no changes to sendmail i am aware of.What may produce this error > >is an error in the libc that may be in the 0210 snapshot. Not sure about it. > >If you have enough space and the source loaded, look into lib/libc/gen/getcwd.c. > >If this uses something like a getenv("PWD") somewhere in the code, try to get > >a newer version of this file and replace that in the library. > > Thank rkw@dataplex who made a new libc and sendmail from > -current. I tried it but unfortunately, the problem did > not go away. Since the libc and libc.so is such a globally > needed library, I suspect it is not safe to simply replace > them and compile sendmail and pray for the world peace. I > might want to go back to 0202SNAP if I can find it. Or even > 2.0-RELEASE? When is next snap shot? I guess I lost the original posting. What exactly is the problem here, beside that someone somewhere thinks that the unnamed problem is the result of sendmail? Note that there is a bad interaction because of the new resolver library such that sendmail is unable to look up hosts and it sticks in the queue. This because there was a change to the resolver to get rid of the static initialization of global data, specificially the default retry count. Sendmail saves a 0 value (it used to be 4) and restores it after the the initialization takes place. This should have been fixed in a newer sendmail, since relying on the resolver's global state preinitialization is a bad thing to do. Supposedly sendmail would explicitly call the resolver init as long as it was not in a debug mode that thwarted the resolver, when the final patch had been made. Perhaps your problem is updated resolver code in the libc used to build sendmail? One of the symptoms of this was that the initial send would fail and the mail would sit in the queue until explicitly flushed out or a timeout occurred. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.