Sun-Spots-Request@Rice.edu (William LeFebvre) (10/03/88)
SUN-SPOTS DIGEST Saturday, 1 October 1988 Volume 6 : Issue 245 Today's Topics: Re: fcntl/lockf locking under 4.0 (2) Re: vms to sun mail Re: gnuemacs keyboard bindings Re: wiring questions (weiss and schwartz) Re: Changing Shared Memory Limitations Re: Interpreting ID PROM info The Horrible 4/110 killing program! saving space in the clients' root filesystem followup on csh/execve problem serious bugs in 4.0 rpc.lockd kermit for sun 4? fileservers 4/280 vs. 3/280? Termcap CX4107? ALM-2 and hardware flow control? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Tue, 27 Sep 88 11:14:59 +1000 From: Craig Bishop <munnari!lupus.cc.deakin.oz.au!craig@uunet.uu.net> Subject: Re: fcntl/lockf locking under 4.0 (1) We have had similar problems, Sun looked at the problem then sent us new binaries for rpc.lockd for both our server which is a 3/280 and our client which is a 4/110. These should fix your problems. Temporarily you can log on to the client then rlogin to the server kill the rpc.lockd and rpc.statd then immediately shutdown the client and reboot it. Things should work until either the client or the server crashes. It sounds wierd but it was the only way we could get it to work. Craig Bishop ARPA: craig%lupus.cc.deakin.oz.au@uunet.uu.net UUCP: ...!uunet!munnari!lupus.cc.deakin.oz!craig ------------------------------ Date: Wed, 28 Sep 88 15:02:18 EDT From: Dan Franklin <dan@wilma.bbn.com> Subject: Re: fcntl/lockf locking under 4.0 (2) We have problems with hanging fcntl() calls under SunOS 3.5. I'm disappointed to hear that 4.0 doesn't fix them. Not only do processes calling fcntl() and lockf() hang if either the local or remote rpc.lockd daemon is dead, but you can't even kill them once they're hung! Presumably they hang in the kernel exit code trying to free the locks on all the file descriptors as they're closed. The problem is particularly bad for us because we have Vaxes running Ultrix 2.[02], which don't have a locking daemon. So things ALWAYS hang when we try to do anything with a file on the Vax. As a temporary work-around we switched to using flock(), so at least multiple invocations of our program on the same workstation will cooperate. We plan to change our code to try using fcntl(), but if it hangs, abandon it and switch to flock() for that file descriptor. Dan Franklin ------------------------------ Date: Tue, 27 Sep 88 09:03:42 CDT From: "Dave Marquardt" <davem@gonzo.eta.com> Subject: Re: vms to sun mail In article <1917@kalliope.rice.edu> you write: >We are attempting to find a way to send mail from our VAXs (VAXEN?) to our >SUN workstations.... Check out PMDF for VMS. The contact person is NED@YMIR.BITNET. PMDF supports a number of different methods of sending and receiving mail, including a couple of different DECnet methods. Dave ------------------------------ Date: Tue, 27 Sep 88 15:05:44 BST From: P.C. Sutton <pcs%MARVIN.BRAD.AC.UK@cunyvm.cuny.edu> Subject: Re: gnuemacs keyboard bindings Andrew Gerber asks: > How would one set up a .emacs file to bind the sun keyboard arrow keys > ([C [A [B [D) to move the cursor around in Emacs? This is very simple. The routine below does this. You can put this in your .emacs file, however it will then be loaded even if you use a different terminal type. To ensure that it is only run when you are using a workstation, put it in a file called `term/sun' somewhere in the emacs load-path. (This assumes that your workstation has its TERMINAL enviroment variable set to `sun'). You can set the load path either within emacs (change the variable `load-path') or by setting the enviroment varible EMACSLOADPATH to include the path to the `term' directory. You can look all this up in the emacs info service, under customization. Hope this is helpful. Paul Sutton | JANET: pcs@uk.ac.bradford.marvin Universty Of Bradford __________ ;; Binds arrow keys sun workstation to move cursor (global-unset-key "\M-[") (define-key global-map "\M-[A" 'previous-line) (define-key global-map "\M-[B" 'next-line) (define-key global-map "\M-[D" 'backward-char) (define-key global-map "\M-[C" 'forward-char) ------------------------------ Date: 27 Sep 88 04:13:01 GMT From: phri!roy@philabs.philips.com (Roy Smith) Subject: Re: wiring questions (weiss and schwartz) Eric Ole Barber <mcvax!nw.stl.stc.co.uk!sizex@uunet.uu.net> said: > I don't think 'live' and 'neutral' would apply in the U.S. since both > pins are 55V with respect to ground Say what!? (or should that be "Say Watt!?" :-)) Live and neutral most certainly do apply in the US. The white wire is neutral, the black, blue, or red wire is hot. Green, if it exists, is ground. You should see a nominal 115V between hot and neutral. The neutral is tied to ground *somewhere*, perhaps at the service entrance to your building. At a typical wall outlet, you'll see some potential difference between ground and neutral, but if you see much more than perhaps 5-10 volts, I'd be surprised. To be sure, if you see 55 volts between neutral and ground, something is seriously wrong and you should immediately call a qualified electrician to correct the problem. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net ------------------------------ Date: Tue, 27 Sep 88 09:10:05 PDT From: weiser.pa@xerox.com Subject: Re: Changing Shared Memory Limitations "I would like to share 4M of data space between processes. However, the system has limits on the amount of space it will allow (~100K)." Under SunOS 4.0 the only limitation I have found is 500MB. Under 3.x, you will need to rebuild the kernel with some new constants in the config file. I added the following to my configs: options SHMPOOL=8096 # max number of shared kbytes, total options SHMSEG=64 # max shared segments per process Hope this helps. -mark ------------------------------ Date: 23 Sep 88 16:11:22 GMT From: step!number1!perl@philabs.philips.com (Robert Perlberg) Subject: Re: Interpreting ID PROM info On my machine, hostid returns 12005496. According to your article, it's telling me that my serial number is 5496. The serial number on the case of my machine is 725E2616. I tried converting 5496 hex to decimal and got 21654. What's the deal? Robert Perlberg Dean Witter Reynolds Inc., New York phri!{dasys1 | philabs | manhat}!step!perl ------------------------------ Date: Tue, 27 Sep 88 13:43:07 PDT From: Darrell long <darrell@midgard.ucsc.edu> Subject: The Horrible 4/110 killing program! We have found that mixing library types is a bad thing to do on a 4/110. The following is the shortest program that demonstrates this problem. If we run it we get a "watchdog reset" and the system is down. I would be interested in hearing if the same happens on other systems running SunOS 4.0. We know that on a 4/260 it only results ina segmentation fault. Regards, DL -- cut -- # # Feed to sh and stand well back. # cat >a.c <<XX main() { printf("dfgdfgdfg\n"); } XX cc -c a.c ld -e start -Bsymbolic a.o /lib/crt0.o -Bstatic -lc a.out ------------------------------ Date: Tue, 27 Sep 88 10:29:16 CDT From: maeder@symcom.math.uiuc.edu Subject: saving space in the clients' root filesystem I have seen some discussion about using one root file system for several clients under 4.0 in the last few weeks, involving terrible hacks. While in the good old 3.x days I myself was rather eager to modify the standard distribution I have now decided to leave it alone as much as possible. Doing all those updates was just a pain. 4.0 is much nicer for sysadmins anyway. Nevertheless I found an easy way of saving a lot of disk space on these root filesystems. Basically you do a normal installation with all the client's roots under /export/root/hostname. Observe that on the server all these root directories are in the same filesystem. You can therefore use HARD links for all files that are the same! This is the case for all identical vmunix files and saves about 600kB per client. The others that save a lot are the binaries in the sbin dirctory saving another 270kB (Don't try to make a hard link for sbin itself...). The rest of the files is not worth linking (most of them are different anyway. The main idea of 4.0 is to have only host specific files in /) A typical (with empty /tmp and /var) root contains about 1.3MB. But all our 8 clients together use up only 3.2MB. To do this let suninstall do a normal install of all clients and then go into each of the root directories except the first one, delete vmunix and link it: ln ../first/vmunix . the go into the sbin subdirectory, delete all the binaries and link them in the same way. In this way you can still have different vmunix files for different clients if you need. Another interesting effect of 4.0 is that now all the clients share the empty space in the root partition. In my example the 8 3/50 clients have a total of about 8MB available on their root filesystem. Each one of them sees the total and can use it for spooling large files etc. On the negative side, if one client decides to fill up /tmp then all clients hang. I wonder whether there is a way to prevent this. Happy hacking, Roman Maeder Univ. of Illinois, Department of Mathematics and Center for Supercomputing Research and Development ------------------------------ Date: Tue, 27 Sep 88 15:20:02 EDT From: schwartz@shire.cs.psu.edu (Scott Schwartz) Subject: followup on csh/execve problem Some time ago I reported (to Sun and to sun-spots) the fact that the c-shell does not behave as documented by its man page with respect to the maximum length of argument lists. Shortly after that posting appeared in sun-spots, I received mail from a knowledgeable insider that basically said they knew about this problem. When they expanded the kernel's maximum value for argument lists they discovered that there was a bug in the c-shell (segmentation faults, or some such thing.) Rather than fix the shell, they simply retained the pre 4.0 limit. /bin/sh, on the other hand, gets it right. Recently I received the (terse) official response from Sun on this issue. Their offical claim is that the csh restricts the length of argument lists for "compatablility". Compatablility??? With what? System V? BSD? Then why did you change the kernel and the other shells? Give us a break! Hey, look, if you want compatability, why not ship a real UUCP with SunOS?? ------------------------------ Date: Thu, 29 Sep 88 13:37:45 -0500 From: abe@mace.cc.purdue.edu (Vic Abell) Subject: serious bugs in 4.0 rpc.lockd Here is more information on the 4.0 fcntl/lock bugs I reported previously. 1) If a client or its rpc.lockd crash, the client rpc.lockd cannot regain contact with its server rpc.lockd. The server receives request from the client but gets an RPC error when it tries to reply. The client processes using fcntl or lockf hang and cannot be killed. However, if both the client and server rpc.lockd processes are killed, the server rpc.lockd is restarted, then the client rpc.lockd is restarted, the client fcntl/lockf processes resume. 2) Client locks on the same are propagated to the clients, but the lock test commands fail between clients. A fcntl(F_GETLK) call always returns F_UNLCK, and lockf(fd, F_TEST, size) always returns zero. However, a client without the lock IS blocked if it attempts to set it - fcntl(F_SETLK) and lockf(F_LOCK/F_TLOCK) return -1. 3) When fcntl and lock return -1 upon sensing a blocked lock, errno is set to EACCESS, not EAGAIN, as documented. 4) Clients and their server do not share locking information properly. The clients do send the lock requests to the server for files shared via NFS, but the server does not recognize that it already has the same lock set for a server process. The server rpc.lockd does, as noted in 2, recognize lock conflicts on the same file when clients make the requests. The state of record locking in 4.0 is appalling. These bugs make it unusable. Vic Abell ------------------------------ Date: 27 Sep 88 03:18:20 GMT From: dave@wucs1.wustl.edu (David T Mitchell III) Subject: kermit for sun 4? Help! Does anyone have a version of kermit which works for the sun 4/280, running sun os 4.0? I tried porting one from our vax with no luck. seems to not receive the acknowledgement when trying to send. thanks, dave dave@wucs1.wustl.edu ------------------------------ Date: Wed, 28 Sep 88 17:50:59 EDT From: warsaw@cme-durer.arpa (Barry A. Warsaw) Subject: fileservers 4/280 vs. 3/280? [[ I got this note in a digest as soon as I could. Hope it's not too late... --wnl ]] I'm currently using a 3/280S as a fileserver for a ~20 node ethernet, with 6 diskless clients, 4 standalones and the rest dataless nodes (all Sun-3's). This fileserver also runs various server processes such as laserwriter and color printer service, CASE tools, Framemaker and HOL's (Ada, etc.) as well as the normal nd, nfs, mail type stuff. We've gotten to a point where we've filled both our 575 Mb drives and we'd like to expand our system. Instead of just sticking another disk drive on the 3/280 (say a 892 Mb drive), we want to go ahead and purchase a second fileserver and split many of the duties between the two servers. My question is this: would it be more advantagous to get a 4/280 server to handle things like diskless clients, printer service and the like, and devote the current 3/280 to nfs service, or will the mixing of architectures (the 4 would be the only non-sun 3 on our network) be more of a hassle than its worth? And does the 4/280 buy us much in terms of the kinds of processing I'll be doing with it? In other words, if you could get a 280S with an 892 Mb drive and 32 Mb of RAM to fit in the network described above, would you buy a Sun-3 or Sun-4 and why? Two notes: 1) all our 3's are running Sun OS3.5 with no plans in the near future to upgrade to 4.0. Will this also cause problems? 2) one of our main consideration is that we provide room to expand our diskless client force. My gut feeling is that the 6 diskless nodes currently hanging off of our 3/280 are about all that system can handle, due mainly to processing power and not disk space limitations. Since I need answers to these questions asap, I'd appreciate it if you could e-mail your responses. I'll summarise and post the results. Thanks very much, -Barry NAME: Barry A. Warsaw USMAIL: National Institute of Standards TELE: (301) 975-3460 and Technology (formerly NBS) UUCP: {...}!uunet!cme-durer!warsaw Rm. B-124, Bldg. 220 ARPA: warsaw@cme-durer.arpa Gaithersburg, MD 20899 ------------------------------ Date: Mon, 26 Sep 88 23:04:32 CDT From: "Rich Winkel" <MATHPG1@UMCVMB.BITNET> Subject: Termcap CX4107? Does anyone have a termcap entry for a Tektronics CX4107? Thanks, Rich Winkel (MATHPG1@UMCVMB.MISSOURI.EDU) ------------------------------ Date: Tue, 27 Sep 88 16:38:32 +0200 From: mcvax!tut.fi!vjk@uunet.uu.net Subject: ALM-2 and hardware flow control? Reference: v6n230 > ...Of course the whole problem could be that the > broadband modems EIA flow control does not work as claimed. Are you sure that your ALM-2 does hardware flow control. None of ALM or mcp manuals tells anything about flow control, and I NEED IT. Vesa ------------------------------ End of SUN-Spots Digest ***********************