onward@fsg.UUCP (Onward Lam) (11/14/90)
Recently had this experience: Had a 6000/3.1 running as the only server in a small (< 5 machines) network. Wanted to remove the 'biod's from startup, since they're client side processes. Went into SMIT, ... , Change number of nfsd and biod daemons Set number of biods to 0 Told it to do it now, and at restart (ie. both) Lo and behold, biod starts to fork itself 'infinitely', resulting in MANY occurrences of /usr/etc/biod 0 System quickly runs out of process slots.... 'press the small round yellow button on the front panel' EXCEPT /usr/etc/biod 0 is invoked again at boot time Has anybody seen this, can somebody confirm/deny it? Incidentally, we didn't have bootable tapes/floppies/cd nearby. This is what we eventually did: When the Console login: prompt comes up: VERY QUICKLY login as root and EQUALLY QUICKLY did this : mv /usr/etc/biod /usr/etc/biodo ; sync and hit the round yellow button again after a short while (for the sync). Wanted to try the same for nfsd's, but sanity prevailed. Onward Lam :-) ..!uunet!fsg!onward "Of course, these are only my opinions, and not necessarily those of my employer"
roger@eccles.psych.nwu.edu (Roger Ratcliff) (11/14/90)
Our IBM SE managed to suggest setting the number to zero over the phone then had to leave. One of our local people suggested loggining in as soon as a login was available (as root) then doing exec mv /etc/rc.nfs /etc/rc.nfs.no i.e., moving out the offending file that sets the number of biod to zero then reboot and you are in to alter the file and set # biod to something nonzero. By the way, each system should come with a big warning message: NEVER EVER mv libc.a. You usually have to reload the system. Roger