Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

SGI admin Frequently Asked Questions (FAQ)
Section - -80- Why isn't the objectserver working?

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]


Top Document: SGI admin Frequently Asked Questions (FAQ)
Previous Document: -79- SGI DAEMONS
Next Document: -81- What is sending packets to the sgi-dog.mcast.net multicast address?
See reader questions & answers on this topic! - Help others by sharing your knowledge

  Install patch 1096. 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 <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. Ken Gant
    <krgant@musetech.com> points out that, as specified in gettydefs(4),
    the last line of /etc/gettydefs must be blank. 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.

  - Tovar ? <tvr@skywebs.com> suggests shutting off your objectserver,
    then running 'objecterver -d'.

  - Urpo Kotipalo <nightis@raita.oulu.fi> had trouble with shadow
    passwords and the objectserver, which he fixed by waiting until
    '/etc/init.d/cadmin clean' had finished running pwconv(1M) before
    doing '/etc/init.d/cadmin start'.


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

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: SGI admin Frequently Asked Questions (FAQ)
Previous Document: -79- SGI DAEMONS
Next Document: -81- What is sending packets to the sgi-dog.mcast.net multicast address?

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
sgi-faq@viz.tamu.edu (The SGI FAQ group)





Last Update March 27 2014 @ 02:12 PM