home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!news.service.uci.edu!unogate!mvb.saic.com!mx-list
- From: "W. Todd Wipke" <wipke@SECS.UCSC.EDU>
- Newsgroups: vmsnet.mail.mx
- Subject: disk full situation
- Message-ID: <0096061D.5B595DC0.23695@SECS.UCSC.EDU>
- Date: Wed, 09 Sep 1992 23:09:26 PDT
- Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
- X-Gateway-Source-Info: Mailing List
- Lines: 24
-
- we recently had the disk on which the MX Queue was located fill up, plus
- the system disk of the machine that runs most of the servers had a board
- failure. Fixing the board brought everything to life (without reboot, ah
- the tolerance of VMS!!!) but the MX Local server kept terminating. It happened
- because MX had made an entry in the Queue (which required no new disk blocks),
- but could not make the file for the headers and src, etc. It required manual
- comparison and canceling entries for which no files existed in order to get
- MX Local out of critical condition and on its feet. A couple years ago I had
- a similar problem for a different reason, msgs couldn't go out for a while
- and the body of the msgs got deleted but the entries in the queue remained.
- It seems like there should be greater rigor to assure that no files
- get deleted unless the entry is removed. Or to help people recover and do
- validity checking, have an mcp queue function that checks each entry in
- the queue against required files in the queue and if there is an entry without
- a file, cancel the entry in the queue. Perhaps this account will inform
- people of things to look for when things don't seem right and deamons die
- repeatedly. MX debug for MX Local was helpful, but process accounting was
- also necessary. I thing a queue validity analysis would be very useful, and
- rather simple.
-
- MX is great! I looked for Matt Madison and the TGV gang at the Capitola
- Sand Castle contest but there were no computer themes there.
- -Todd wipke
- UCSC
-