We are having intermittent issues with BPM, Portal In baskets, Designer and Administrator that gives us an error stating
I have seen this happen in 2 different scenarios: 1) the *lase*.log files have the wrong permissions/owner in $LAWDIR/system:
lawson:/lawson/law/system$ ls -lrt *lase* -rw-rw-rw- 1 root lawson 7 Feb 03 14:24 lase.pid -rw-rw-rw- 1 root lawson 318 Feb 03 14:24 lase.log -rw-rw-rw- 1 root system 648 Feb 03 14:24 lase_server_0.log -rw-rw-rw- 1 root system 0 Feb 03 17:40 lase_server_0.log.lck -rw-r--r-- 1 lawson lawson 648 Feb 03 17:41 lase_server_1.log
These files need to be chown lawson and chmod 644;
2) There was a WAS JVM environment variable for com.lawson.logdir ....in addition to com.lawson.lawdir, com.lawson.gendir, and com.lawson.ladbdir...do you have that?
I had a similar problem...this is from an LIS case "I've seen this problem a few times and it's always been log permissions. I'm certainly open to the idea that it could be something else, but I want to make sure that we've covered every possible base with respect to logs and permissions first. To answer your final question, my suggestion to restart the server is for two reasons: First, to make sure that all of Lawson (including ProcessFlow) is running as the lawson user. This will make sure that new logs that get created are owned by lawson, as well. If ProcessFlow is running as one user and Lawson is running as another, that will add an extra layer of confusion in troubleshooting this. The second reason, is that I'm not certain that the server recovers from this problem just by changing log permissions without a restart. It may be the case that after the error occurs, it will continue to occur even if the root cause is addressed, absent a restart of the servers. So the bottom line is that to be absolutely assured that everything is as it should be, I believe that everything should be stopped (with a stoplaw), the permissions/ownership checked, and then everything strarted up with a startlaw, executed as the lawson user." Check the lase logs; and does your "pfserv stop all" work? check for bpm after stopping. ps -ef | grep bpm >> output file
I had a similar problem...this is from an LIS case "I've seen this problem a few times and it's always been log permissions. I'm certainly open to the idea that it could be something else, but I want to make sure that we've covered every possible base with respect to logs and permissions first. To answer your final question, my suggestion to restart the server is for two reasons: First, to make sure that all of Lawson (including ProcessFlow) is running as the lawson user. This will make sure that new logs that get created are owned by lawson, as well. If ProcessFlow is running as one user and Lawson is running as another, that will add an extra layer of confusion in troubleshooting this. The second reason, is that I'm not certain that the server recovers from this problem just by changing log permissions without a restart. It may be the case that after the error occurs, it will continue to occur even if the root cause is addressed, absent a restart of the servers. So the bottom line is that to be absolutely assured that everything is as it should be, I believe that everything should be stopped (with a stoplaw), the permissions/ownership checked, and then everything strarted up with a startlaw, executed as the lawson user."
Check the lase logs; and does your "pfserv stop all" work? check for bpm after stopping. ps -ef | grep bpm >> output file