Hi all,
[Debian unstable x86]
I've been having some big problems trying to get INN2 to run. I had it
successfully running and I was able to make a post as localhost but now
I find it has stopped working again. I have only made some innocuous
changes (nothing that would cause the problems set out below)
After installing task-news-server I had to run dpkg-reconfigure inn2 for
the history files to be created. At first it didn't work.
I now receive the message "IIND: No active file!" when I try and start
the news server.
I've traced the error message into rc.news. The reason no active file is
found, and nothing else works, is that the path variables such as ACTIVE
are empty (PATHBIN etc are empty as well).
I have traced the setting of the path variables to inn.conf. pathdb is
valid and sets the location of the active etc. files.
First /etc/init.d/inn2 is started:
#! /bin/sh
#
# init.d/inn2 Start/stop the news server.
#
test -f /usr/lib/news/bin/innd || exit 0
start () {
su news -c /usr/lib/news/bin/rc.news
}
So all we see here is that inn2 just swiches execution to rc.news
running as user news.
So let's look at rc.news:
#! /bin/sh
. /usr/lib/news/innshellvars
Ah, this is where the paths are set.
The permissions on innshellvars are root:root rw,r,r
I have never seen the use of a dot-space-path before. I guess this is
the way of inserting an external script into a running script. I have
checked the Debian stable inn2 source and the notation is similar:
. @LIBDIR@/innshellvars
so it doesn't appear to be a typo.
Now if I add an "echo ${PATHLIB}" or "echo ${ACTIVE}" into this script I
find the paths are empty and /active respectively. Obviously active
won't be found in the root directory.
So now I check out /usr/lib/news/innshellvars and discover that this is
how the paths are retrieved:
eval `/usr/lib/news/bin/innconfval -s`
I can execute this from the command line and many of the variables are
in the shell environment. However variables such as PATHDB are missing,
even though they are clearly in the /usr/lib/news/bin/innconfval -s
output.
Could this all be caused by too little space to store all the new
environment variables? Should I receive an error message if this is
happening?
Many thanks,
Adam
