shull@SCROLLS.WHARTON.UPENN.EDU (Christopher E. Shull) (02/09/89)
Anybody know off the top of their head how I can fix the following problem
with BSD4.2 TCP/IP 3.1 sendmail under SR9.7.1:
# newaliases
cannot make /usr/lib/aliases.pag: Bad file number
The alternative command:
$ /usr/lib/sendmail -bi
yields the identical result. Although I don't see any clues therein,
here are some views of the files:
# ls -l /usr/lib/aliases.pag
-rw-rw-rw- 1 root 1024 Dec 16 14:29 /usr/lib/aliases.pag
# ls -l /usr/lib/aliases.dir
-rw-rw-rw- 1 root 0 Feb 8 18:24 /usr/lib/aliases.dir
$ ld /usr/lib/aliases.?* -a
sys type blocks current
type uid used length attr rights name
file uasc 3 2866 P pgndwrx /usr/lib/aliases.bak
file uasc 1 32 P pgndwrx /usr/lib/aliases.dir
file uasc 2 1056 P pgndwrx /usr/lib/aliases.pag
3 entries listed, 6 blocks used.
Thanks for any help you can offer.
-Chris
Christopher E. Shull
Decision Sciences Department
The Wharton School shull@wharton.upenn.edu
University of Pennsylvania shull@scrolls.wharton.upenn.edu
Philadelphia, PA 19104-6366 215/898-5930
---------------------------------------------------------------------------
"Damn the torpedoes! Full speed ahead!" Admiral Farragut, USN, 1801-1870
---------------------------------------------------------------------------dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (02/10/89)
WRT posting <8902090246.AA08349@scrolls.wharton.upenn.edu> > Anybody know off the top of their head how I can fix the following problem > with BSD4.2 TCP/IP 3.1 sendmail under SR9.7.1: > > # newaliases > cannot make /usr/lib/aliases.pag: Bad file number I can think of two possible causes for this problem and an easy fix for both of them. 1) These are "UASC" type files and as such have a streams header that could be corrupt. On most pre-sr10 files there is a 32 byte header that is used by the streams file type managers to store file attributes. (try a /com/ld -si) This header is why an "empty" UASC file is 32 bytes in size. The header has a check-sum and if the file wasn't properly closed, then the check-sum would be wrong. To check for this, try reading the file with an Aegis tool such as a DM read or a /com/catf. If you get the error message "system (or process) crash prevented complete file close" then the streams header is corrupt. 2) The file may be locked by a remote process. In general Unix programs don't understand a file system that has mandatory file locking and they get unhappy when they can't open a file that has a remote lock on it. check the "locked objects list" and see if the aliases.pag file is listed in it. Do a "/com/lllob | /com/fpat aliases" to check for a lock on the file. The fix is simple, rename the existing aliases database files to something else then run newaliases. EG: "/com/chn /usr/lib/alises.% =.old" Once the new aliases file are created the old ones can safley be deleted. Note that any sendmail daemons (sendmail -bd) will need to be killed and restarted to "see" the new aliases database. Dave Funk
geof@apolling (Geof Cooper) (02/10/89)
In article <8902090246.AA08349@scrolls.wharton.upenn.edu> shull@SCROLLS.WHARTON.UPENN.EDU (Christopher E. Shull) writes: > >Anybody know off the top of their head how I can fix the following problem >with BSD4.2 TCP/IP 3.1 sendmail under SR9.7.1: > > # newaliases > cannot make /usr/lib/aliases.pag: Bad file number I believe that the problem is that the file is open by another node and is locked against updating. My usual approach is to delete /usr/lib/aliases.{pag,dir} and then run newaliases. The program complains that it can't open a file, but works correctly. Run it twice if the error message bothers you. I find that it is better to be CRP'd onto the node where the file is resident before running "newaliases".
shull@SCROLLS.WHARTON.UPENN.EDU (Christopher E. Shull) (02/11/89)
Thanks to the folks who offered suggestions on my "newaliases -> cannot make
/usr/lib/aliases.pag: Bad file number" problem. In case anyone wonders, I
tried a whole bunch of different things short of shutting down the system,
but in the end, I had to shut and reboot. Only this seems to solved this
problem.
My next question is how folks deal with TCP/IP problems. Again, I am running
BSD4.2 TCP/IP 3.1 on SR9.7.1. The only common problem is the dreaded:
socket: I/O error
from the telnet, ftp, and mail programs. I currently recommend the following
steps to my users:
1) "# ps -aug" or "$ pst" to make sure desirable
processes are not running on the node,
2) logout,
3) exit (from the "login:" prompt),
4) go ( at the ")" prompt),
5) log back in and try again.
This seems to work 99% of the time, but sometimes shutting down all the way
is necessary.
-Chris
Christopher E. Shull
Decision Sciences Department
The Wharton School shull@wharton.upenn.edu
University of Pennsylvania shull@scrolls.wharton.upenn.edu
Philadelphia, PA 19104-6366 215/898-5930
---------------------------------------------------------------------------
"Damn the torpedoes! Full speed ahead!" Admiral Farragut, USN, 1801-1870
---------------------------------------------------------------------------george@HYPER.LAP.UPENN.EDU (George "Sir Lleb" Zipperlen) (02/11/89)
Re: the dreaded tcp/ip socket error. Do you have the right version of
the streams library? I remember having to get a patch for this last
spring. I can't remember whether this was fixed in SR 9.7.1
anyway, ts /lib/streams should be:
/lib/streams: Program_Module
Name = STREAMS
Time Stamp: 1988/05/06 11:52:53 EST (Fri)
or later, I think. Most of the other SR9.7 libraries we have
are stamped 1987 or earlier.
--
George Zipperlen george@apollo.lap.upenn.edu george@hyper.lap.upenn.edu
...!{rutgers, harvard, mit-eddie, decwrl}!upenn.edu!apollo.lap!george
Blatant plug for funky-music@apollo.lap.upenn.edu "Won't be no Static" -JB