From SRA at XX.LCS.MIT.EDU Wed Jun 22 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Wed 22 Jun 88, 00:00 Subject: No subject In-Reply-To: <440792.880622.ZVONA@MC.LCS.MIT.EDU> Message-ID: <12408610560.16.SRA@XX.LCS.MIT.EDU> Date: Wed, 22 Jun 88 21:28:11 EDT From: David Chapman Why can't I link to a non-disk device? The AI: device, in particular? Presumably because the UFD definition for links allows SNAME, FN1, & FN2 but doesn't allow device names. See AI:SYSTEM;FSDEFS. Also presumably because by the time you get to deciphering links the filesystem code just knows that it must be dealing with a disk device. Neither of which is a reason why you -shouldn't- be able to link to non-disk devices, just why you can't. ------- From ZVONA at MC.LCS.MIT.EDU Thu Jun 23 03:28:11 1988 From: ZVONA at MC.LCS.MIT.EDU (David Chapman) Date: Jun 22 88 21:28:11 EDT Subject: No subject Message-ID: <440792.880622.ZVONA@MC.LCS.MIT.EDU> This is a stupid question, but maybe someone won't mind educating me: Why can't I link to a non-disk device? The AI: device, in particular? From SRA at XX.LCS.MIT.EDU Thu Jun 16 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Thu 16 Jun 88, 00:00 Subject: well, I hope there's SOME explanation for this In-Reply-To: Message-ID: <12407034826.27.SRA@XX.LCS.MIT.EDU> Date: Thu, 16 Jun 1988 19:39 EDT From: PGS at XX.LCS.MIT.EDU This is not a joke. This happens consistently on XX. [PHOTO: Recording initiated Thu 16-Jun-88 7:33PM] MIT TOPS-20 Command Processor 5(312162)-2 No mail. @whois yomama yomama at mc [MC.LCS.MIT.EDU] -User- --Full name-- Jobnam Idle TTY -Console location- ALAN ` Alan Bawden P 1:18 T05 723 x8843 Alan, HQM (Spaceman) [AI] Hacking too many things for my own good Birthday January 23; NE43-723; 3-8843; Home Phone 492-7274 29 Reed St., Cambridge, MA 02140 @pop [PHOTO: Recording terminated Thu 16-Jun-88 7:34PM] The bug is in the Twenex finger program. The only explaination I can think of is that the guy who wrote the parsing code in that program had his brain held hostage on planet Quorgon while he was writing that part of it. The amazing thing is that the program runs at all. Even more amazing is that it ever works in server mode, considering that it gets its JCL by each FINGER stuffing its RFC packet into the CHARFC job's shared RSCAN% buffer. I suppose I might try to fix this some day, but since it only catches a subset of completely bogus names I don't intend to worry about it much. ------- From PGS at XX.LCS.MIT.EDU Fri Jun 17 01:39:00 1988 From: PGS at XX.LCS.MIT.EDU (PGS at XX.LCS.MIT.EDU) Date: Jun 16 1988 19:39 EDT Subject: well, I hope there's SOME explanation for this Message-ID: This is not a joke. This happens consistently on XX. [PHOTO: Recording initiated Thu 16-Jun-88 7:33PM] MIT TOPS-20 Command Processor 5(312162)-2 No mail. @whois yomama yomama at mc [MC.LCS.MIT.EDU] -User- --Full name-- Jobnam Idle TTY -Console location- ALAN ` Alan Bawden P 1:18 T05 723 x8843 Alan, HQM (Spaceman) [AI] Hacking too many things for my own good Birthday January 23; NE43-723; 3-8843; Home Phone 492-7274 29 Reed St., Cambridge, MA 02140 @pop [PHOTO: Recording terminated Thu 16-Jun-88 7:34PM] But, come to think of it: Alan, can I go to the dance on Saturday night? Oh, come on, pleeeeeze?! From DCP at QUABBIN.SCRC.Symbolics.COM Thu Jun 16 01:15:00 1988 From: DCP at QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Date: Jun 15 88 19:15 EDT Subject: This is important! In-Reply-To: <19880615210705.7.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <19880615231501.4.DCP@SWAN.SCRC.Symbolics.COM> Date: Wed, 15 Jun 88 17:07 EDT From: Alan Bawden ... Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer ... BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) I'd be interested in understanding why. Is it because the thing that times out connections might not actually shut down the connection, but would cause the 3600 to forget about it, this accumulating even more useless connections? Anytime the control connection dies (either because the network spazzed, or because the scavenger closes it), the next file operation will find this control connection (ConnA), notice it is dead, reset it (here's the bug: which forgets about it), reestablish connection, and then use ConnA for the duration of this single file operation. The next file operation will not even find ConnA and must therefore cons up a new one (ConnB). ConnB will be found for a while. When it dies, it will still be found (once), get forgotten about and used, and then ConnC must be consed up. So... The more often the file connection scavenger runs, the faster the connections die, so the higher the rate of finding/forgetting and thus leaving open but connections around. ... Which finally brings me to the real point of the message. Unfortunately, despite Symbolic's best efforts (for which I thank them), we are still left in a situation where we have to get zapped at least once by a site before we can send them the fix. We can spread the fix around ourselves to the most likely places, but we can still lose now and then. Therefore, unless anybody objects or has a better plan, I plan to install a tasteless little demon that checks for FTP and GATEWAY servers that are clearly idle, and guns them down. That should be an effective defense against any future offenders. (I'll have it keep a log of what it does, so that we can still spot the losers and send them the patch.) Sounds fine to me. I'd use 20 minutes as idle, which I think gives the typical 15 minute connection scavenger a chance first. Also, be careful what you call "idle." LispMs will issue reset-provoking-probes at rather short intervals, so you should measure idle by actualy byte (sequence number) traffic, not last-time-a-packet-seen (since chaos has a stronger are-you-alive idle probe). I guess this is just process idle time... From Alan at AI.AI.MIT.EDU Wed Jun 15 23:07:00 1988 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Jun 15 88 17:07 EDT Subject: This is important! In-Reply-To: <19880611005711.2.KAO@BINKLEY.SCH.Symbolics.COM>, <19880613151342.8.KAO@BINKLEY.SCH.Symbolics.COM>, <12406136710.21.SRA@XX.LCS.MIT.EDU>, <19880613161443.4.MAEDA@PELE.ACA.MCC.COM>, <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM>, <12406155402.19.SRA@XX.LCS.MIT.EDU>, <19880613221658.4.CJL@OTIS.AI.MIT.EDU>, <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM>, <19880614211637.8.DCP@SWAN.SCRC.Symbolics.COM>, <19880615034707.7.CJL@OTIS.AI.MIT.EDU>, <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM>, <880615114233.8.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <19880615210705.7.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 13 Jun 88 08:13 PDT From: kao at VERMITHRAX.SCH.Symbolics.COM [Response from the developer. Hope it helps.] Certainly a quick work around for this would be to reduce the file-control-lifetime for MC to something less than 15 minutes and make sure all the machines see the namespace update. Although we haven't done this anywhere (unless our friends at MCC have done this?) this is a reasonable suggestion which did not occur to me when I spotted the problem initially. Please thank the unnamed developer for me. Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. [ Aside to Gumby: The problem with GATEWAY connections is only that someone who uses Chaos TCP-GATEWAY service on MC to access a remote FTP server winds up using zillions of Chaos -and- TCP connections on MC. I suppose you are trying to say that if the problem with FTP connections gets solved, the problem with GATEWAY connections goes away. This is correct. ] Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer ...I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it.... I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test.... BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) I'd be interested in understanding why. Is it because the thing that times out connections might not actually shut down the connection, but would cause the 3600 to forget about it, this accumulating even more useless connections? Date: Tue, 14 Jun 88 23:47 EDT From: Chris Lindblad I added this to our local 7-2-patches system. It will get loaded into most machines here when they boot. Of course this isn't much of a test, since (as far as I know) all the machines that load 7-2-Patches are machines that can talk CHAOS QFILE to all the ITS machines, and they also talk TCP, so there is no reason they should need CHAOS GATEWAY service either. Date: Wed, 15 Jun 88 11:42 CDT From: David Vinayak Wallace This patch appears to have a bug (which I have reported to DCP). I would not suggest supplying it to the unwary. Now if Gumby and Maeda at MCC try this patch out, that will be a real test. As soon as they are satisfied that it works, then we can think about handing it out to other sites that we discover causing this problem in the future. Which finally brings me to the real point of the message. Unfortunately, despite Symbolic's best efforts (for which I thank them), we are still left in a situation where we have to get zapped at least once by a site before we can send them the fix. We can spread the fix around ourselves to the most likely places, but we can still lose now and then. Therefore, unless anybody objects or has a better plan, I plan to install a tasteless little demon that checks for FTP and GATEWAY servers that are clearly idle, and guns them down. That should be an effective defense against any future offenders. (I'll have it keep a log of what it does, so that we can still spot the losers and send them the patch.) From Gumby at MCC.COM Wed Jun 15 18:42:00 1988 From: Gumby at MCC.COM (David Vinayak Wallace) Date: Jun 15 88 11:42 CDT Subject: This is important! In-Reply-To: <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM> Message-ID: <880615114233.8.GUMBY@BRAHMA.ACA.MCC.COM> Date: Wed, 15 Jun 88 08:14 PDT From: kao at VERMITHRAX.SCH.Symbolics.COM Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden 1 In Symbolics 3640 Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, Metering Substrate 26.7, Metering 11.1, Hacks 14.1, IP-TCP 67.5, ILA-NFS 9.6, 7-2-Patches 1.8, MAC 14.5, TeX-DVI 2.2, QUIC 2.0, IMPRESS 2.0, LPD 2.2, Pascal Runtime 20.0, Compiler Tools Package 11.0, Compiler Tools Runtime 21.0, Pascal Package 9.0, Syntax Editor Runtime 4.0, TeX-SCT 2.1, TeX-Doc 2.0, TeX-Common 2.0, VIRTeX 2.0, TeX 2.0, LaTeX 2.0, SliTeX 2.0, YTeX 2.0, BibTeX 2.0, Illustrate 13.1, Macsyma 412.45, microcode 3640-MIC 420, FEP 127, FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233, Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2) on Symbolics 3640 #5233 (Hilbert's Nullstellensatz): 0 Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). Here is the patch written by DCP. It fixes the bug you reported. This patch appears to have a bug (which I have reported to DCP). I would not suggest supplying it to the unwary. From kao at VERMITHRAX.SCH.Symbolics.COM Wed Jun 15 17:14:00 1988 From: kao at VERMITHRAX.SCH.Symbolics.COM (kao at VERMITHRAX.SCH.Symbolics.COM) Date: Jun 15 88 08:14 PDT Subject: This is important! In-Reply-To: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> References: <12405426732.27.SRA@XX.LCS.MIT.EDU>, <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Message-ID: <19880615151443.1.KAO@BINKLEY.SCH.Symbolics.COM> Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden 1 In Symbolics 3640 Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, Metering Substrate 26.7, Metering 11.1, Hacks 14.1, IP-TCP 67.5, ILA-NFS 9.6, 7-2-Patches 1.8, MAC 14.5, TeX-DVI 2.2, QUIC 2.0, IMPRESS 2.0, LPD 2.2, Pascal Runtime 20.0, Compiler Tools Package 11.0, Compiler Tools Runtime 21.0, Pascal Package 9.0, Syntax Editor Runtime 4.0, TeX-SCT 2.1, TeX-Doc 2.0, TeX-Common 2.0, VIRTeX 2.0, TeX 2.0, LaTeX 2.0, SliTeX 2.0, YTeX 2.0, BibTeX 2.0, Illustrate 13.1, Macsyma 412.45, microcode 3640-MIC 420, FEP 127, FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233, Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2) on Symbolics 3640 #5233 (Hilbert's Nullstellensatz): 0 Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Here is the patch written by DCP. It fixes the bug you reported. ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: USER; Base: 10; Patch-File: T -*- ;;; Patch file for Private version 0.0 ;;; Reason: Removing the connection from the file access path should not ;;; be part of the contract of resetting the connection. ;;; Function (FLAVOR:METHOD :RESET FS:TCP-FTP-CONN): Don't remove. (Doing so is "silly" anyway.) ;;; Remove function (FLAVOR:METHOD :REMOVE-CONN FS:TCP-FTP-FILE-ACCESS-PATH): No longer needed. ;;; Function (DEFUN-IN-FLAVOR FS:TCP-FTP-FIND-CONN FS:TCP-FTP-FILE-ACCESS-PATH): Interact properly with multiple processes. ;;; Written by DCP, 6/14/88 16:18:34 ;;; while running on Swan from MAMA-CASS|FEP1:>SCRC-7-2-E-from-IH-Genera-7-2-C.load.1 ;;; with Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, ;;; Nsage 27.175, Documentation Database 62.18, Metering Substrate 26.7, ;;; Metering 11.1, Hacks 14.1, IP-TCP 67.5, DNA 41.6, Version Control 52.9, ;;; Compare Merge 18.0, Experimental Lock Simple 19.0, VC Documentation 12.0, ;;; Symbolics In-House 16.7, Symbolics In-House Documentation 6.3, ;;; Experimental Statice 53.0, Unique-ID 11.2, DBFS 54.16, DBFS Utilities 9.0, ;;; Statice-Index 15.0, Statice-Record 26.1, Statice-Model 51.15, ;;; Statice Documentation 16.0, Experimental Statice Examples NEWEST, DBFS-DIR 25.4, ;;; Statice-Utilities 14.4, Tertiary Storage 10.0, DBFS Maintenance 12.0, ;;; Volume Librarian 9.0, Bug Tracking 24.11, Symbolics Boston 17.2, SCRC 37.0, ;;; Experimental Ndomains 18, microcode 3640-MIC 420, FEP 127, ;;; FEP0:>V127-lisp.flod(61), FEP0:>V127-loaders.flod(61), FEP0:>V127-tests.flod(61), ;;; FEP0:>v127-debug.flod(37), FEP0:>V127-ddt.flod(61), FEP0:>V127-info.flod(61), ;;; Machine serial number 4968, ;;; Be more imaginative than "Run" (from Q:>dcp>ideas>info-giving-process-preemption.lisp.8), ;;; System patches for 7.1 domain implementation (from Q:>dcp>domains>system-patches.lisp.5). (NOTE-PRIVATE-PATCH "TCP-FTP: Interact properly with DELETE operation") ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-") ;; Connections (defmethod (:reset tcp-ftp-conn) () (setq login-state nil) (setq state :free) (when telnet-stream (send telnet-stream :close :abort) (setq telnet-stream nil)) (when data-stream (send data-stream :close :abort) 2(setq data-stream nil)0) (when aux-stream (send aux-stream :close :abort) (setq aux-stream nil)) 2;; Don't remove the connection. Doing so causes all sorts of grief. 0 2;; There are some parts of the code that :RESET the connection and 0 2;; then proceed to open up a new telnet-stream (e.g., 0 2;; 0tcp-ftp-validate-conn2) and there are others that dolist the conns, 0 2;; and removing a conn out from under them isn't very fun at all! 0 2;; 0(send file-access-path :remove-conn self) ) ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-") (FUNDEFINE '(FLAVOR:METHOD :REMOVE-CONN TCP-FTP-FILE-ACCESS-PATH)) ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "SYS:IP-TCP;TCP-FTP.LISP.1527") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SYSTEM; Base: 10; Lowercase: Yes -*-") (defun-in-flavor (tcp-ftp-find-conn tcp-ftp-file-access-path) () (loop for conn in conns when (send conn :allocate) return conn finally 2(let ((new-conn 0(make-instance 'tcp-ftp-conn :file-access-path self :service-access-path service-access-path)2)) 0 2(without-interrupts 0 (push 2new-conn 0conns)2) 0 (send *file-connection-scavenger* :run-reason self) (return 2new-conn0)2)0)) From cjl at WHEATIES.AI.MIT.EDU Wed Jun 15 05:47:00 1988 From: cjl at WHEATIES.AI.MIT.EDU (Chris Lindblad) Date: Jun 14 88 23:47 EDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: The message of 14 Jun 88 17:16 EDT from David C. Plummer Message-ID: <19880615034707.7.CJL@OTIS.AI.MIT.EDU> Date: Tue, 14 Jun 88 17:16 EDT From: David C. Plummer Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Yup. Legit bug in the Slime mold. I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it. I figured out how to reproduce the problem and this file does appear to fix it. I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test. I didn't compile the file. On the LispM end, this also fixes the orphan TCP (FTP) connection bug, which accompanies the ITS/TWENEX manifestation. I added this to our local 7-2-patches system. It will get loaded into most machines here when they boot. BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end." From DCP at QUABBIN.SCRC.Symbolics.COM Tue Jun 14 23:15:00 1988 From: DCP at QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Date: Jun 14 88 17:15 EDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <19880614211534.7.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Yup. Legit bug in the Slime mold. I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it. I figured out how to reproduce the problem and this file does appear to fix it. I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test. I didn't compile the file. On the LispM end, this also fixes the orphan TCP (FTP) connection bug, which accompanies the ITS/TWENEX manifestation. Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end." From DCP at QUABBIN.SCRC.Symbolics.COM Tue Jun 14 23:16:00 1988 From: DCP at QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Date: Jun 14 88 17:16 EDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM> Message-ID: <19880614211637.8.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 13 Jun 88 22:20 CDT From: David Vinayak Wallace The problem is with FILE connections, not GATEWAY connections. From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Yup. Legit bug in the Slime mold. I'm pretty sure the code in Zermatt.LCS.MIT.EDU:>dcp>tcp-ftp-delete.lisp fixes it. I figured out how to reproduce the problem and this file does appear to fix it. I still need to run it by the person current maintainer (who isn't the author) for a sanity check. Having you folks run it would be a good use-test. I didn't compile the file. On the LispM end, this also fixes the orphan TCP (FTP) connection bug, which accompanies the ITS/TWENEX manifestation. BTW, I think decreasing the file control lifetime would make the problem WORSE!! (I'm not sure about that, though.) Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end." From Gumby at MCC.COM Tue Jun 14 05:20:00 1988 From: Gumby at MCC.COM (David Vinayak Wallace) Date: Jun 13 88 22:20 CDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <19880613221658.4.CJL@OTIS.AI.MIT.EDU> Message-ID: <880613222026.8.GUMBY@BRAHMA.ACA.MCC.COM> The problem is with FILE connections, not GATEWAY connections. >From poking into it (my machine is one of the main instigators) it looks like only Symbolics' implementation of FTP is to blame. Isn't it nice to have a network problem which ISN'T due to unix violating the spec? At least this way we can get it fixed rather than be told "Look, it works with all the unix systems I try; you must have a problem at your end." From cjl at WHEATIES.AI.MIT.EDU Tue Jun 14 00:16:00 1988 From: cjl at WHEATIES.AI.MIT.EDU (Chris Lindblad) Date: Jun 13 88 18:16 EDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <12406136710.21.SRA@XX.LCS.MIT.EDU> Message-ID: <19880613221658.4.CJL@OTIS.AI.MIT.EDU> Date: Mon 13 Jun 88 11:44:20-EDT From: Rob Austein My impression is that this really isn't enough, given that MC's hostname seems to be wired into two zillion pieces of Lispm code (at least, 1I can't find anything in the namespace that would explain the way lispms always offer to use MC as a gateway0). Also, the fact that this approach only works if every namespace that includes a reference to MC gets the update and nobody anywhere decides to make the lifetime longer again. Right. I also believe in the tooth fairy.... The lisp machines use MC as a gatway because the namespace says it supports the TCP-GATEWAY service. 2Showing HOST MC in namespace LCS: 0... 1Service: TCP-GATEWAY CHAOS TCP-GATEWAY 0... But I figured I'd give somebody else a chance to tell me that I'm an ignorant barbarian and that the fix is sufficient. I personally doubt the fix will be sufficient. From SRA at XX.LCS.MIT.EDU Mon Jun 13 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Mon 13 Jun 88, 00:00 Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM> Message-ID: <12406155402.19.SRA@XX.LCS.MIT.EDU> Date: Mon, 13 Jun 88 13:01 EDT From: David C. Plummer [Don't shoot the messenger!! I intend to look into this when I get out from under a week's worth of mail. But don't tell my co-workers that, nor as a promise I'll find a fix.] On that basis, I'm still glad to hear this. Thanks for whatever you find time to do.... Is it really easier to load a patch on ALL the machines than it is to change a FEW namespaces? Moot point, since (almost) all the Tech Square Lispms do automatic world load installation. In any case, it is definitely more permanent to fix the code, too many people can and do edit the namespace for me to trust anything that can wipe out an important machine this completely to a namespace entry. Also, once we have a patch we can tell the owners of offending machines to either install the patch or lose access to MC. At the moment there's no constructive action we can ask offenders to take. ------- From DCP at QUABBIN.SCRC.Symbolics.COM Mon Jun 13 19:01:00 1988 From: DCP at QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Date: Jun 13 88 13:01 EDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <19880613161443.4.MAEDA@PELE.ACA.MCC.COM> Message-ID: <19880613170125.3.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 13 Jun 88 11:14 CDT From: Christopher Maeda Umm, What should we hicks at MCC set our file control lifetimes for MC to? Since we have such a large lab contingent here, our Texas based namespace features such favorites as XX, AI, and yes, MC. Changing all those namespaces would be kind of hard, especially since ours is supposed to be secure against the outside world. [Don't shoot the messenger!! I intend to look into this when I get out from under a week's worth of mail. But don't tell my co-workers that, nor as a promise I'll find a fix.] Is it really easier to load a patch on ALL the machines than it is to change a FEW namespaces? Give em hell, Rob, Chris From maeda at MCC.COM Mon Jun 13 18:14:00 1988 From: maeda at MCC.COM (Christopher Maeda) Date: Jun 13 88 11:14 CDT Subject: File-Control-Lifetime "fix" for MC FTP connections In-Reply-To: <12406136710.21.SRA@XX.LCS.MIT.EDU> Message-ID: <19880613161443.4.MAEDA@PELE.ACA.MCC.COM> Umm, What should we hicks at MCC set our file control lifetimes for MC to? Since we have such a large lab contingent here, our Texas based namespace features such favorites as XX, AI, and yes, MC. Changing all those namespaces would be kind of hard, especially since ours is supposed to be secure against the outside world. Give em hell, Rob, Chris From SRA at XX.LCS.MIT.EDU Mon Jun 13 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Mon 13 Jun 88, 00:00 Subject: File-Control-Lifetime "fix" for MC FTP connections Message-ID: <12406136710.21.SRA@XX.LCS.MIT.EDU> So, is the feeling that this workaround (setting file control lifetime to something short for MC) sufficient or should I yell at Symbolics some more? My impression is that this really isn't enough, given that MC's hostname seems to be wired into two zillion pieces of Lispm code (at least, I can't find anything in the namespace that would explain the way lispms always offer to use MC as a gateway). Also, the fact that this approach only works if every namespace that includes a reference to MC gets the update and nobody anywhere decides to make the lifetime longer again. Right. I also believe in the tooth fairy.... But I figured I'd give somebody else a chance to tell me that I'm an ignorant barbarian and that the fix is sufficient. --Rob ------- From kao at VERMITHRAX.SCH.Symbolics.COM Mon Jun 13 17:13:00 1988 From: kao at VERMITHRAX.SCH.Symbolics.COM (kao at VERMITHRAX.SCH.Symbolics.COM) Date: Jun 13 88 08:13 PDT Subject: This is important! In-Reply-To: <12405426732.27.SRA@XX.LCS.MIT.EDU> References: <12405426732.27.SRA@XX.LCS.MIT.EDU>, <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Message-ID: <19880613151342.8.KAO@BINKLEY.SCH.Symbolics.COM> Date: Fri 10 Jun 88 18:44:18-EDT From: Rob Austein Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! Message-ID: <19880610214220.1.ALAN at NULLSTELLENSATZ.AI.MIT.EDU> Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Ahem. I, Robert Austein, Systems Programmer in the MIT Laboratory for Computer Science Computational Resources group, HostAdmin etcetera of MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this bug that Alan has reported ASAP and stop abusing the Mail Cruncher. This is pretty clearly not a MIT-specific bug because I've seen this same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC in Austin, Texas. If this request is not sufficient I'll kick this matter upstairs to the people who negotiate contracts with Symbolics and let them yell at you, but that's a lot of hassle for everybody so let's not. RSVP ASAP. Thanks. --Rob ------- [Response from the developer. Hope it helps.] Certainly a quick work around for this would be to reduce the file-control-lifetime for MC to something less than 15 minutes and make sure all the machines see the namespace update. To change FTP from using multiple connections would be a major architectural change and would divert from the norms used for other file protocols. I don't think that multiple connections are the problem here, cleaning up after them is what is causing the pain. There are some long standing bugs that are very difficult to reproduce and track down that affect connection cleanup for FTP connections. The easiest work around that I know of is the short file-control-lifetime in the host object. From kao at VERMITHRAX.SCH.Symbolics.COM Sat Jun 11 02:57:00 1988 From: kao at VERMITHRAX.SCH.Symbolics.COM (kao at VERMITHRAX.SCH.Symbolics.COM) Date: Jun 10 88 17:57 PDT Subject: This is important! In-Reply-To: <12405426732.27.SRA@XX.LCS.MIT.EDU> Message-ID: <19880611005711.2.KAO@BINKLEY.SCH.Symbolics.COM> Date: Fri 10 Jun 88 18:44:18-EDT From: Rob Austein Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! Message-ID: <19880610214220.1.ALAN at NULLSTELLENSATZ.AI.MIT.EDU> Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Ahem. I, Robert Austein, Systems Programmer in the MIT Laboratory for Computer Science Computational Resources group, HostAdmin etcetera of MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this bug that Alan has reported ASAP and stop abusing the Mail Cruncher. This is pretty clearly not a MIT-specific bug because I've seen this same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC in Austin, Texas. If this request is not sufficient I'll kick this matter upstairs to the people who negotiate contracts with Symbolics and let them yell at you, but that's a lot of hassle for everybody so let's not. RSVP ASAP. Thanks. --Rob ------- Request noted. The bug-report/fix-request has been forwarded to the development people and software support supervisor. We'll get back to you by the end of next week. From SRA at XX.LCS.MIT.EDU Fri Jun 10 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Fri 10 Jun 88, 00:00 Subject: This is important! In-Reply-To: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> Message-ID: <12405426732.27.SRA@XX.LCS.MIT.EDU> Date: Fri, 10 Jun 88 17:42 EDT From: Alan Bawden Subject: This is important! Message-ID: <19880610214220.1.ALAN at NULLSTELLENSATZ.AI.MIT.EDU> Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints. Ahem. I, Robert Austein, Systems Programmer in the MIT Laboratory for Computer Science Computational Resources group, HostAdmin etcetera of MC.LCS.MIT.EDU, do hereby lodge an official request that you fix this bug that Alan has reported ASAP and stop abusing the Mail Cruncher. This is pretty clearly not a MIT-specific bug because I've seen this same thing happen to XX.LCS.MIT.EDU when the culprit is a Lispm at MCC in Austin, Texas. If this request is not sufficient I'll kick this matter upstairs to the people who negotiate contracts with Symbolics and let them yell at you, but that's a lot of hassle for everybody so let's not. RSVP ASAP. Thanks. --Rob ------- From Alan at AI.AI.MIT.EDU Fri Jun 10 23:42:00 1988 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Jun 10 88 17:42 EDT Subject: This is important! Message-ID: <19880610214220.1.ALAN@NULLSTELLENSATZ.AI.MIT.EDU> 1In Symbolics 3640 Genera 7.2, Experimental Logical Pathnames Translation Files NEWEST, Metering Substrate 26.7, Metering 11.1, Hacks 14.1, IP-TCP 67.5, ILA-NFS 9.6, 7-2-Patches 1.8, MAC 14.5, TeX-DVI 2.2, QUIC 2.0, IMPRESS 2.0, LPD 2.2, Pascal Runtime 20.0, Compiler Tools Package 11.0, Compiler Tools Runtime 21.0, Pascal Package 9.0, Syntax Editor Runtime 4.0, TeX-SCT 2.1, TeX-Doc 2.0, TeX-Common 2.0, VIRTeX 2.0, TeX 2.0, LaTeX 2.0, SliTeX 2.0, YTeX 2.0, BibTeX 2.0, Illustrate 13.1, Macsyma 412.45, microcode 3640-MIC 420, FEP 127, FEP0:>v127-lisp.flod(64), FEP0:>v127-loaders.flod(64), FEP0:>v127-debug.flod(38), FEP0:>v127-info.flod(64), Machine serial number 5233, Patches for Alan (from B:>alan>rel-7-2-patch.lisp.2) on Symbolics 3640 #5233 (Hilbert's Nullstellensatz): 0Please, please, please, do something about the bug where when a 3600 uses TCP/FTP as a file access path it sometimes starts up dozens of FTP servers on the file server. Twice now I have found MC.LCS.MIT.EDU with all of its network connections used up because someone somewhere was using FTP to access files on MC (or on some remote machine with MC serving as a CHOAS/TCP gateway). I would appreciate a fix for this problem -quickly- because MIT depends on MC.LCS.MIT.EDU for moving a fair amount of mail, and this bug totally disables the machine. This is the kind of problem where I can get somebody at MIT with an official sounding title to call you all up on the phone and lodge "official" complaints.