Subject:   -77- Why isn't the objectserver working?
Date: 03 Dec 1995 00:00:01 EST

  Install patch 617. If you still have problems, read on.

  First, consider whether you really need the objectserver. Without it,
  you'll lose "business cards" and the graphical admin software. They're
  probably not worth the headache.

  Anne Eagle <annee@sgi.com> posted most of the following:

  - Its database may be corrupt. If the objectserver appears to start
    OK but crashes later, this is probably the case. Rebuild it like
    so:

      /etc/init.d/cadmin stop
      /etc/init.d/cadmin clean
      /etc/init.d/cadmin start

    If the preceding doesn't work, try this

      /etc/init.d/cadmin stop
      mv /var/Cadmin/data /var/Cadmin/data.old
      /usr/Cadmin/bin/parseclasses
      /etc/init.d/cadmin start

    Note that either method destroys "Privileged User" and "Business
    Card" information. (This is the ONLY known drawback of rebuilding
    your objectserver database, and the ONLY reason why SGI
    documentation recommends that you consult with the TAC before doing
    so. For most people that means that there's no reason why you
    shouldn't rebuild whenever the need arises.)

  - One of your system configuration files (including but not limited to
    /etc/exports, /etc/fstab, /etc/inittab, /etc/mtab, /etc/passwd and
    /etc/printcap) may have minor format problems which don't bother
    IRIX proper but do bother the objectserver. Such problems include a
    last line which doesn't end with a linefeed, a backspace not
    preceded by a space in /etc/exports, or unprintable characters.
    Gary Lin of SGI <glin@csd.sgi.com> suggests that you ensure that
    /etc/exports has explicit -ro or -rw export options and that you
    remove continuation lines (\) from /etc/printcap.  One sign that you
    have such a problem is a core file in /var/Cadmin/data.  If you find
    and fix a problem, rebuild the databases as above.

    If you can't find the problem, try the following:

      par -s -i -N open -l -SS /usr/Cadmin/bin/objectserver -d

    The last file objectserver opens is probably where the problem is.
    If you're really desperate, the TAC will give you an objectserver
    compiled with -g and help you run dbx on it.

  - You may be swamping the objectserver with NIS (YP) users. There are
    several ways around this:

    - Start a directoryserver on a machine on your local network.

    - Use netgroups or the "+user" form in /etc/passwd instead of just
      a "+" and rebuild the databases as above.

    - Most severely, remove the NIS object definition files so that the
      objectserver will not create NIS objects, rebuild the
      objectserver database (without the NIS objects) and restart the
      objectserver as follows. You will not be able to manipulate NIS
      users with Cadmin if you do this.

      killall fm
      mediad -k
      killall objectserver
      mv /var/Cadmin/data /var/Cadmin/data.orig
      cp -pr /usr/Cadmin/classes /usr/Cadmin/classes.orig
      rm /usr/Cadmin/classes/groupObject.op
      rm /usr/Cadmin/classes/nisAccountObject.op
      rm /usr/Cadmin/classes/peopleNISObject.op
      rm /usr/Cadmin/classes/peopleObject.op
      /usr/Cadmin/bin/parseclasses
      /usr/Cadmin/bin/objectserver
      ps -ef | grep obj
      
      Wait until you see 2 objectserver processes running, then do

      mediad
      fm -lrb &

  - Chris Riney <chris.riney@tandy.com> says: "We have just discovered
    here at our site that if you do not have a route defined for the
    SGI multicast subnet, then objectserver will gobble up memory.  I
    established a route for 224.0.0.0, and objectserver has been up for
    over a week without consuming additional memory." This route is
    defined in the stock /etc/init.d/network.

  - Andreas Klingler <andreas.klingler@rrze.uni-erlangen.de> fixed his
    objectserver by removing /usr/Cadmin/classes/printerObject.op and
    then rebuilding /var/Cadmin/data as above.

  - David Carrigan <vermeer@panix.com> fixed his objectserver by editing
    his /etc/passwd file so userids were in ascending order.

  See also "Indigo Magic Tips and Tricks" in the Sep/Oct 1994 Pipeline
  and the entry on the imon queue below.