SUMMARY: inetd and calendar manager

From: Meystel (meystel@impaqt.drexel.edu)
Date: Sun Oct 31 1993 - 01:47:16 CST


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



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:27 CDT