man pages problem

[Crazza]

I have an IBM Intel-based server running SCO OpenServer Enterprise Edition (5.0.5). <br><br>I'm not quite sure what has caused the problem but every time I try to access the 'man' pages, I cannot get a response.<br><br>For example, if I try:<br><br># man ps<br><br>I get <br><br>man: ps not found<br><br>And this is true of every command I can think of. None of the man pages are accessible.<br><br>Can anyone throw any light on this for me?<br><br>Thanks<br><br>Craig Shepherd

 

[Annihilannic]

Crazza,<br><br>Difficult to diagnose from here... but I guess a start would be to check /usr/man and see if there's anything there?&nbsp;&nbsp;A typical machine would have about 100 files and directories there.&nbsp;&nbsp;Next check the permissions; on one of the machines I look after they're mostly owned by user bin/group bin, and everyone has read access to them.<br><br>Let us know how you go.<br><br>Annihilannic.

 

[Crazza]

Annihilannic,<br><br>Thanks for the swift response.<br><br>The files in&nbsp;&nbsp;/usr/man/ (and there are quite a lot of them) are almost all user - bin, group - bin and 644 permissions. <br><br>There are a few exceptions though, the files 'index' and 'whatis' are both user - root, group - root and 644 permissions.<br><br>While I am not sure of the exact cause of this problem it _may_ and I stress that as I can't be certain, have something to do with the /etc/default/lang file. I had to amend that in the past to allow a piece of software to run on the server. The problem is that I'm not certain that 'man' stopped working after I did this. I have dabbled with /etc/default/lang to see if it helped but 'man' has never worked. This may be coincidental but I thought it best to mention as I believe that they are linked via the system locale settings (I think) and it might have a bearing on the problem.<br><br>Thanks again for your time on this<br><br>Craig Shepherd<br>

 

[Annihilannic]

Crazza,<br><br>Hmm... that all sounds fine.&nbsp;&nbsp;The man pages on OpenServer are served by the scohttpd daemon... check whether it is running.&nbsp;&nbsp;I don't think this is the problem though because when I stop mine and type 'man ps' I get<br><br>&nbsp;&nbsp;&nbsp;man : can't connect to scohttp<br>&nbsp;&nbsp;&nbsp;man: ps not found<br><br>Try doing an 'integrity -e' to check for broken links, etc. especially with respect to /etc/default/man and the files in /var/scohttp/conf.<br><br>You can also check whether scohttpd is working properly by connecting to the URL <A HREF="

http://yourmachinename:457/dochome.html"

TARGET="_new">

http://yourmachinename:457/dochome.html</A>

and choosing the 'Reference Documentation Set' link (in fact this is useful for browsing the man pages under normal circumstances).<br><br>I can't think of anything else!<br><br>Annihilannic.

 

[Crazza]

Annihilannic,<br><br>I think I've got the answer though maybe a sort-of solution. We are using scohttpd to drive our internal Intranet.&nbsp;&nbsp;To avoid filling up the root filesystem, we put the Intranet HTML files in /u/intranet and changed the DocumentRoot parameter in /var/scohttp/conf/srm.conf to /u/intranet/ rather than /usr/lib/scohelp. It made sense at the time as we were advised that scohttpd would manage the limited Intranet facilities that we need.<br><br>Scohttpd works fine as our Intranet is in constant use but I hadn't realised that this would impact on the man pages. <br><br>I've done a partial test of this on another SCO box and I have been able to recreate the 'man: not found' error by changing DocumentRoot, restoring the original value fixes the problem. I think you've cracked it.<br><br>As far as fixes go, I am actually in the process on setting up an Apache server on a Linux box to take over Intranet duties so when that's done I can simply restore the value of DocumentRoot on the SCO box and the man pages should work as normal.<br><br>Thanks for your help, at least I know what's causing it now and I can get to work on fixing it.<br><br>Cheers<br><br>Craig Shepherd