The following KB could be start for you (though it is mentioned against 7.6):
Thank you, Kedar. Unfortunately this link does not work for me. Is it an internal document? Could you make it available for me?
can you attach the appserver log that shows this or a snippet of the log ?
Excuse me, Bill, for answering that late... Unfortunately the logfiles containing that message are on a customer's system which I haven't access to right now. I tried to simulate the situation in my test environment but (of course ) the message did not appear. I think I'll be back at the customer in January or Feburary.
I am not able see the doc..
telling that it has been removed..
1 of 1 people found this helpful
it seems that there is an issue with secure file(either the file itself or the content of the file)..
by default path is /usr/lib/rsc/secure
check the content of the file as well as check if the file has necessary permission..
if the job you running form root then 600 permission will work but if you want any user (other than root), then you need to give 644 permission..
the content should be (if you are using TLS protocol only)
check with these..
Thank you for your sharing your thoughts.
After a while (...) I'm back at the customer and stumbled over this message in the appserver-log again. I checked what you proposed and found:
ls -l secure gives
-rw-r--r-- 1 root root 154 Apr 13 2011 secure
What may be a reason is, that we have a local installation and the secure-file is in
Could this be the problem?
The content looks like:
could be the reason..!!
1 of 1 people found this helpful
it probably means you installed the appserver w/ the -local flag and the secure file was not being read out of NSH/conf/secure on startup because of an incorrect concatenation of variables in the code. this should be fixed shortly. can you open up a support ticket on this ?
i believe the worst that would happen is that you would be unable to use any custom options in the secure file.
If you do an strace (if this is Linux) you will find a line in the code that returns ""strace.out.28901:10:43:58 stat64("/data1/test/NSH/confsecure", 0xb7eefb00) = -1 ENOENT (No such file or directory)" this appea Defect QM001791221 with description ""strace.out.28901:10:43:58 stat64("/data1/test/NSH/confsecure", 0xb7eefb00) = -1 ENOENT:"
This is an indication of what Bill was referring to. We encountered this recently at another customer site where an 8.1.5 hotfix was created. But as Bill said, open a support ticket for tracking and let's make sure that we confirm this is exactaly the same issue.
Thank you Alan and Bill - seems to be the root-cause - I will check this next time at the customer.
BTW - on which command did you run strace? The AppServer binary/bytecode?
I ran the strace against the /etc/init.d/blappserv start command. I can dig up the syntax for it if you'd like.
Can you please forward us the syntax? That will be helpful.
Sorry, I forgot to send this to you.
If you run the strace:
1. su - bladmin
2. "strace -t -f -o strace.out /etc/init.d/blappserv start"
3. "grep confsecure strace.out"
You will see an entry that resembles
"stat("/opt/bladelogic/appserver/NSH/confsecure", 0x41726280) = -1 ENOENT (No such file or directory)"