inetd and calendar manager

2007-12-25 8:33:00

Hi,

This was the original problem:

> I am running a SparcStation IPC with SunOS 4.1.3 and OpenWindows 3.0

> I cannot run my calendar manager! Even though I ran install_cmgr, I get

> the following errors:

> -console error:

> Oct 14 10:44:54 cerebrum inetd[175]: 100068/rpc/udp server failing (looping),

> service terminated

> This happens when starting up the Calendar Manager. And the Calendar Manager

> itself says "rpc.cmsd not responding. Have you run install_cmgr?"

> This happens despite the facts that:

> - I DO have a rpc.cmsd process running (owner: daemon, state: IW)

> - the inetd.conf file has the following lines:

> # rpc.cmsd is a data base daemon which manages calendar data backed

> # by files in /usr/spool/calendar

> 100068/2-3 dgram rpc/udp wait root /usr/openwin/bin/rpc.cmsd rpc.cmsd

> And despite this entry in inetd.conf,

> rpcinfo -u `hostname` 100068

> returns

> rpcinfo: RPC: Program not registered

> program 100068 is not available

Thanks to:

Tim Evans (tkevans@fallst.es.dupont.com)

Charles Dennett (dennett@kodak.com)

Jochen Bern (bern@kleopatra.uni-trier.de)

Brian Farrell (farrell@mr.med.ge.com)

Steve Pomush (spomush@amgen.com)

Mike Detringer (mike@galt.osd.mil)

Carl Gabrielson (carl@aspec.com)

Claus Assmann (ca@informatik.uni-kiel.de)

Eric Wimer (eric@finsun.gatech.edu)

James Terry (james@sybase.com)

Some responses are below. The general consensus is that rpc.cmsd is an

unfriendly process, and that it is necessary to either re-run install_cmgr

every time inetd.conf is changed, or to kill the running cmsd, kill -HUP the

inetd and start the calendar manager again. One person suggested that there

is a Calendar Manager patch to install, and another suggested an inetd patch.

I haven't looked at those patches yet, so I have no comment on their

effectiveness.

tkevans@fallst.es.dupont.com (Tim Evans):

  check for blank lines in inetd.conf

farrell@mr.med.ge.com (Brian Farrell):

  kill the rpc.cmsd that is running.

  check the portmapper to see if it exits.

  if it did, do rpcinfo -d cmsd <ver>

  Start the Calendar Manager and see if the rpc.cmsd starts.

  It may be necessary to kill -HUP the inetd process.

ca@informatik.uni-kiel.de (Claus Assmann):

  We have a similar problem and I kill rpc.cmsd, kill -HUP inetd, and

  restart the calendar manager. I sent a bug report to Sun but they

  couldn't find an error. They suggested to restart inetd as a workaround.

eric@finsun.gatech.edu (Eric Wimer):

  We had the same problem, and it was solved by re-enabling the rusers

  service in the inetd.conf file, kill -HUP the inetd, and restarting

  the rpc.cmsd process.

jamest@sybase.com (James Terry):

  Ensure that the services map is without blank lines

dennett@kodak.com (Charles Dennett)

  Install patch 100523-09 which includes a new rpc.cmsd. The patch is actually

  a replacement for inetd which alows to specify how many requests you

  can get and in what time span before it thinks there is a 'looping'

  problem.

bern@kleopatra.uni-trier.de (Jochen Bern):

  The two replies to my cmsd problem stated that it is necessary to re-run

  install_cmgr every time the /etc/inetd.conf file is changed, and that it

  is necessary to install Patch 100178-08 (increasing inetd's File Descriptor

  Limit)

Thanks again for all of the helpful and quick responses. Sorry for the delay

in summarizing.

-Mike

-----

Michael A. Meystel

Systems & Network Administration

IMPACT Center, College of Engineering

Drexel University, Philadelphia, PA USA

+ 1 215 895 5807 / meystel@impact.drexel.edu

Comments

Got something to say?

You must be logged in to post a comment.