oyang@bruce.cs.monash.OZ.AU (Kai Shing O'Yang) (04/24/91)
Is it possible to have named pipes across NFS? What I want to have is a server that writes to the pipe while other client machines try to read from it. My application doesn't require the output to be serialised. I tried it on SunOS 3.5 and Ultrix 3.1 and it didn't work. Thanks in Advance, Kai Shing -- - Kai S O'Yang, Dept of Comp Sci, Monash Uni, Clayton VIC 3168, Australia - AARNET: oyang@bruce.cs.monash.edu.au - Voice : +(61) 3 565 5778 - ARPA : oyang@bruce.cs.monash.edu.au@uunet.uu.net ------
barmar@think.com (Barry Margolin) (04/25/91)
In article <4021@bruce.cs.monash.OZ.AU> oyang@bruce.cs.monash.OZ.AU (Kai Shing O'Yang) writes: >Is it possible to have named pipes across NFS? What I want to have is >a server that writes to the pipe while other client machines try to read >from it. My application doesn't require the output to be serialised. >I tried it on SunOS 3.5 and Ultrix 3.1 and it didn't work. No. The NFS protocol has no provision for such use. NFS only supports reading and writing directories and ordinary files. In the case of other file types, the client machine interprets type-specific attributes (e.g. major and minor device numbers for device special files) locally. In the case of named pipes, the directory entry is just a name for a pipe, and pipes are implemented entirely within the local kernel (didn't Jonathan Kamens just answer this question a day or two ago?). Why does it need to be a named pipe? If the server and clients can be on different machines, why not just use a regular file? Named pipes are simply optimizations that exist for processes on the same host. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
it1@Isis.MsState.Edu (Tim Tsai) (04/25/91)
barmar@think.com (Barry Margolin) writes: [lines deleted] >pipes are implemented entirely within the local kernel (didn't Jonathan >Kamens just answer this question a day or two ago?). Yes he did.. I was the one that asked the question.. >Why does it need to be a named pipe? If the server and clients can be on >different machines, why not just use a regular file? Named pipes are >simply optimizations that exist for processes on the same host. In my case, I have my .plan set up as a named pipe and a daemon that searches the process table for the finger process when awaken. This will only catch fingerers from the local host, which was fine, but if a NFS-mounted station tries to read my .plan, it blocks, and causes erratic behavior with the daemon until .plan is read from the original host. >-- >Barry Margolin, Thinking Machines Corp. >barmar@think.com >{uunet,harvard}!think!barmar -- Never argue with a fool, people might not know the difference. <Murphy's Law>
barmar@think.com (Barry Margolin) (04/26/91)
In article <it1.672572450@Isis.MsState.Edu> it1@Isis.MsState.Edu (Tim Tsai) writes: > In my case, I have my .plan set up as a named pipe and a daemon that >searches the process table for the finger process when awaken. This >will only catch fingerers from the local host, which was fine, but if a >NFS-mounted station tries to read my .plan, it blocks, and causes >erratic behavior with the daemon until .plan is read from the original >host. I see. This is a difficult problem to solve, unless you can arrange to run your daemon on every system that mounts your home directory. Even if named pipes worked across NFS, what would you expect the result of this to be? How would you find the fingerer in the process table when the fingerer is on a different system? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
it1@Isis.MsState.Edu (Tim Tsai) (04/26/91)
barmar@think.com (Barry Margolin) writes: >In article <it1.672572450@Isis.MsState.Edu> it1@Isis.MsState.Edu (Tim Tsai) writes: >> In my case, I have my .plan set up as a named pipe and a daemon that >>searches the process table for the finger process when awaken. This >>will only catch fingerers from the local host, which was fine, but if a >>NFS-mounted station tries to read my .plan, it blocks, and causes >>erratic behavior with the daemon until .plan is read from the original >>host. >I see. This is a difficult problem to solve, unless you can arrange to run >your daemon on every system that mounts your home directory. We have at least 7 machines mounting the users' file systems, which makes that VERY impractical. Not to mention that my account will probably be yanked if I decide to do something like that.. :-) >Even if named pipes worked across NFS, what would you expect the result of >this to be? How would you find the fingerer in the process table when the >fingerer is on a different system? Normally I just put "can't locate the fingerer" on the log file, but I thought about parsing netstat, and then start a remote shell on the machines that I do have access to.. It was just an interesting project to play with, not to get any work done or anything.. The best solution would be to modify fingerd, but that's impossible without root access. >-- >Barry Margolin, Thinking Machines Corp. >barmar@think.com >{uunet,harvard}!think!barmar -- Never argue with a fool, people might not know the difference. <Murphy's Law>
fwp1@CC.MsState.Edu (Frank Peters) (04/26/91)
it1@Isis.MsState.Edu (Tim Tsai) writes: >barmar@think.com (Barry Margolin) writes: >>In article <it1.672572450@Isis.MsState.Edu> it1@Isis.MsState.Edu (Tim Tsai) writes: >>> In my case, I have my .plan set up as a named pipe and a daemon that >>>searches the process table for the finger process when awaken. This >>>will only catch fingerers from the local host, which was fine, but if a >>>NFS-mounted station tries to read my .plan, it blocks, and causes >>>erratic behavior with the daemon until .plan is read from the original >>>host. >>I see. This is a difficult problem to solve, unless you can arrange to run >>your daemon on every system that mounts your home directory. This won't work. If you start up 5 named pipe daemons on 5 machines all waiting on the same nfs mounted physical file the last one works and the first 4 hang. This is on SunOS. I can't speak for other implementations. Worse, the finger hangs if the query is remote. When the remote fingerer kills his/her finger the finger and fingerd processes on our end have know way of knowing that and just continue to wait. I guess you've passed your finger program around to a few people because I regularly have to kill off a handful of these semi-zombie processes. > We have at least 7 machines mounting the users' file systems, which >makes that VERY impractical. Not to mention that my account will >probably be yanked if I decide to do something like that.. :-) There are 18. You'd probably have most bets covered though if you got it going on the 2 central servers. In that case I'd rather have you get it working right so I can stop having to look for zombie-like finger processes to kill. >>Even if named pipes worked across NFS, what would you expect the result of >>this to be? How would you find the fingerer in the process table when the >>fingerer is on a different system? The finger server I wrote (on a whim the last time the subject came up) would run any random program the user specified. I ran it with the fortune program so that each finger would get a different fortune in the .plan file. I also kept a count of fingerers in the .project file. Not any more useful but it does point out that this technique can be used for more than just capturing lists of fingerers. > Normally I just put "can't locate the fingerer" on the log file, but I >thought about parsing netstat, and then start a remote shell on the >machines that I do have access to.. It was just an interesting project >to play with, not to get any work done or anything.. The best solution >would be to modify fingerd, but that's impossible without root access. I've considered modifying finger so that it ignores non-text .plan and .project files (many systems come with finger so modified). That would solve my problem nicely. Wouldn't help you much though (unless you consider making the question moot to be a help). -- Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState Phone: (601)325-2942 FAX: (601)325-8921