Up: SGI admin Frequently Asked Questions (FAQ)
Next: -81- What is sending packets to the sgi-dog.mcast.net multicast address?
Previous: -79- SGI DAEMONS
Subject: -80- Why isn't the objectserver working?
Date: 24 Aug 1996 00:00:01 EST
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.
Up: SGI admin Frequently Asked Questions (FAQ)
Next: -81- What is sending packets to the sgi-dog.mcast.net multicast address?
Previous: -79- SGI DAEMONS