Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
2.3.1
-
None
-
None
-
Kubuntu Jaunty amd64
Description
The phoenix.sh script has a little snippet which auto-detects the PHOENIX_HOME location by following symbolic links from the script itself, recursively. This snippet has a bug - if any of those links are relative, things get screwed up and PHOENIX_HOME is mis-detected.
Example use case:
When installing James as a daemon on linux (at least some common distros), the standard procedure is to make a link from /etc/init.d/james to the phoenix.sh script (wherever it was installed), and then use the update-rc.d utility to set it up to start at boot time as a daemon. This creates additional links from the rcX.d directories to the relative ../init.d/james link. See service wrapper docs and james wiki for run-as-service instructions which suggest this procedure.
When the system is booted this way, the relative links break the script and cause PHOENIX_HOME to be detected as "/", which creates new directories under the root (/logs and /temp), and of course causes James to fail to start (with the error logs not showing up in their expected location for troubleshooting).
Workaround:
Set (export) PHOENIX_HOME explicitly in the script, and comment out or delete the auto-detecting snippet.
Suggested fix:
Unfortunately I'm not experienced enough in shell scripts, but I did find that on some unix systems (including linux) the single "readlink -f" command can follow all symbolic links recursively, and for other systems an online search found a couple of suggested shell snippets that do the same using standard commands. I'm sure the phoenix.sh script itself can be fixed directly to account for relative links as well, but I don't know which is the right/best way to do it.