Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!emory!att!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B Funk)
Newsgroups: comp.sys.apollo
Subject: Re: PRSVR dies.
Message-ID: <9104090921.AA09930@icaen.uiowa.edu>
Date: 9 Apr 91 09:02:09 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 36

in posting <1991Apr04.001427.13506@cs.fau.edu>, Tim McKenzie writes:

>My prsvr keeps aborting from when called within the /etc/rc.user
>file. When I run the same command with the same config file
>all goes great. I have tried cpo, cps, and /bin/nohup in front
>of the command below, but with no success in keeping the sucker
>alive from bootup.
>/sys/hardcopy/prsvr /sys/hardcopy/hp_config &

This sounds like either an ACL problem or some kind of timing
problem.
   The daemons that are started from the rc.user file
run with the SID of "user.server.none". Have you tried creating
an account "user.server.none", logging in to it and then running
the prsvr from that shell? This is one sure-fire way to find
ACL problems. Under sr10.2, the prsvr wants to create a manager
object in "/sys/mgrs" so if the world (or user.server.none) doesn't
have write rights to /sys/mgrs, then your prsvr won't run from
the rc.user file.
  It is possible that the prsvr is getting started before the prmgr
is ready to register it. You might try to move the prmgr to a different
node, so that it is not booting at the same time that the prsvr is.
  Check the system proc_dump log to see if prsvr is leaving a trace-back
error report. Just after boot up do a "tb -last 3" to see what the
last few process crash reports were. Also you could try adding a
std-out & err-out redirection in the "rc.user" file to direct any
error messages from prsvr into a file. Try something in your rc.user like:

(/sys/hardcopy/prsvr /sys/hardcopy/hp_config > /tmp/prsvr.log 2>&1 ) &

This will direct all messages from prsvr into the file "/tmp/prsvr.log"
You don't want to run prsvr this way for normal operation, as prsvr is
rather "chatty" and that file would grow with continued use. However it
is good for a debugging session.

Dave Funk