> > (You can see whether inetd/xinetd registered it with the portmapper by
> > going "rpcinfo -p | grep fam"; if you don't get anything, it wasn't
> > registered. If you do get something like this...
> ok when i do rpcinfo there is no such command for that heh so i donno what
> to tell you......
Is /usr/sbin in your $PATH? If not, does /usr/sbin/rpcinfo -p work?
> and these are the files that are in me xinetd.d directory:
> and here is what they say in each :::
Hoo, hey, look at that: http://www.xinetd.org/
Bummer. From the FAQ:
Q. xinetd doesn't work well with RPC, I need RPC and I really want to
run xinetd. Can I?
A. Yes. xinetd and inetd should happily coexist. Have your RPC stuff run
from your normal inetd (removing all other services from your
inetd.conf), then have xinetd run all your other services.
fam does use RPC, sort of; libfam makes an RPC call to ask the portmapper
what port to connect on.
On the other hand, xinetd source does come with a program for converting
inetd.conf to xinetd.conf; here's what it gave me for fam's entry:
# itox didn't give this next line, but looking at the files
# from your RH7 box make me think it might be a good idea.
disable = no
type = RPC
rpc_version = 1-2
socket_type = stream
protocol = tcp
wait = yes
user = root
server = /usr/local/bin/fam
Try putting that in /etc/xinetd.d/fam, and going "killall -HUP xinetd"
(hopefully that's one similarity between inetd & xinetd... according to
the FAQ, it "understands different signals", and the unofficial tutorial
says you should use -USR1 or -USR2, so you might try one of those if -HUP
doesn't work). Then try running "/usr/sbin/rpcinfo -p | grep fam" to
see whether xinetd registered it with the portmapper.
Let me know where that doesn't work. If we can get it to work through
xinetd, that will be best, but if we can't do that, there are a couple
of other ways we can do it.
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx