Hi, I received the following error when trying to install version 5.3.9.160:
“Warning: Problem running post-install step. Installation may not complete correctly. Error setting passwords for Lucee admins. (did the service start?)”
Can anyone help? Thanks.
OS: Linux 20.04
Java Version: 1.8
Lucee Version: 5.3.9.160
I did the installation on some ubuntu machines (tls 20.04), too and didn’t receive this error.
Did lucee start? Can you login at the server admin?
Hi Michael, thanks for your reply. It inspired me to take another look and I think I’ve managed to solve it. It seems that the installation script couldn’t find the jre already installed in the system - after choosing the option to install the jre along with lucee, it worked! I’d never had to do this before when installing earlier versions, it just seemed to pick up the system jre. Anyway, thanks again!
I’m running into this same problem on Ubuntu 22.04. I receive the same error (“Problem running post-install”) and looking in the logs it says that “/opt/lucee/jre/bin/java” is missing. In my case, I’m using OpenJDK on my laptop and Corretto in my build environment, both installed as deb packages and available as /usr/bin/java (and /usr/lib/jvm/default-java)
I also tried dropping back to the 5.3.9.141 and .133 versions, but they fail with “Error running /opt/lucee/sys/change_user.sh root /opt/lucee lucee nobackup: /bin/sh: 1: /opt/lucee/sys/change_user.sh: not found”
Thoughts? Would be nice to use the system java, and I guess I can just replace the “jre” directory with a link to the default-java directory at the end of the build.
Thanks!
Ubuntu is based upon the beta version of Debian stable
In testing on the latest patched version of 22.04 with lucee 5.3.160
The installer does identify java being installed but fails to complete the final steps in setting up the password or final builder scripted settings.
To make this “work”
env | grep JAVA
If this is blank go to your java version directory (to verify the version you have)
cd /usr/lib/jvm/
If you have java 11 installed you would type in
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
echo $JAVA_HOME
PATH=$PATH:$JAVA_HOME/bin
echo $PATH
Then go to /opt/lucee/tomcat/bin/ (or where ever you installed it)
./configtest.sh
./startup.sh
Thanks for those pointers. I set these environment variables before running the installer:
export JAVA_HOME=/var/lib/jvm/default-java
PATH=$JAVA_HOME/bin:$PATH
It then runs through and, as you suggested, fails with:
Timeout reached waiting for tomcat to start
Problem running post-install step. Installation may not complete correctly
Error setting passwords for Lucee admins. (did the service start?)
Then if I run the configtest/startup it seems to start.
For my script, I think I’m going to go back to using the bundled JRE, from looking at my script it looks like that might have been the default in 5.3.8.201 (my build script worked there, and then goes on to use the /opt/lucee/jre tools to import a key, which is why I’m saying it looks like that was the default). I had read through release notes in the 5.3.9 series, but didn’t see anything about that changing.
Is there some change that needs to happen in the installer to fix this problem? What I’m seeing is this in the install log:
/opt/lucee/tomcat/bin/catalina.sh: 1: eval: /opt/lucee/jre/bin/java: not found
I took a look at the Lucee source and lucee-installer and I can’t even find a reference to catalina.sh. I might need a couple pointers, but I or one of my Java compatriots might be able to get this fixed.
The installer script, needs a dialog to tell everyone that Ubuntu is unsupported, or requires the bundled installer version of Java.
The correct use of JAVA in any OS is, the PATH is added to the OS environment. Ubuntu implementation of JAVA does not do this.
My suggestion is use another distro.
cat /dev/not-helpful
I’m guessing this might be related to the newer installer option which autodetects an installed java, it’s not quite working properly on linux just yet, it seems
Ubuntu does not follow any kind of UNIX standards, which would include adding the JAVA path environment variables to the OS system paths. The issue is with UBUNTU, or the ApacheTomcat team not completely rewritting the catalina.sh to support Ubuntu. If you really want to get into the catalina.sh / bat which checks for OS PATH variables, which are not set in Ubuntu.
As root
useradd -m -d /opt/tomcat -U -s /bin/false tomcat
apt install openjdk-11-jre-headless
vi /etc/environment
add the following lines by pressing the "i" key
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
echo $JAVA_HOME
PATH=$PATH:$JAVA_HOME/bin
echo $PATH
hit the "escape key"
press enter
hit the ":" key
press enter
type in "wq"
press enter
paste this into the console one line at a time and press enter at each line
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
echo $JAVA_HOME
PATH=$PATH:$JAVA_HOME/bin
echo $PATH
wget https://cdn.lucee.org/lucee-5.3.9.160-linux-x64-installer.run
chmod +x lucee-5.3.9.160-linux-x64-installer.run
./lucee-5.3.9.160-linux-x64-installer.run
Hit enter
Hit enter
Hit Y, press enter
Hit Enter
Hit 1, press enter
type a password, hit enter
hit enter or enter a numeric value
hit enter or enter a numeric value
type in tomcat
hit enter or change port value
hit enter or change port value
hit enter or change port value
hit enter or change value (Y /n)
hit enter or change value (Y /n)
hit enter to complete install (Y/n)
You will see "Warning: Problem running post-install step. Installation may not complete correctly
Error setting passwords for Lucee Admins. Press enter to continue,
vi /etc/systemd/system/lucee.service
press “i”
type in or copy and paste the following:
[Unit]
Description=Apache Tomcat Lucee
After=network.target
[Service]
Type=forking
User=tomcat
Group=tomcat
Environment=JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
Environment=CATALINA_PID=/opt/lucee/tomcat/tomcat.pid
Environment=CATALINA_HOME=/opt/lucee/tomcat
Environment=CATALINA_BASE=/opt/lucee/tomcat
Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"
ExecStart=/opt/lucee/tomcat/bin/startup.sh
ExecStop=/opt/lucee/tomcat/bin/shutdown.sh
ExecReload=/bin/kill $MAINPID
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
hit “:”
type in “wq”
now type in
systemctl daemon-reload
press enter
vi /opt/lucee/tomcat/lucee-server/context/password.txt
press “i”
type in a password you want for lucee
press “:”
type in “wq”
now
chown tomcat:tomcat /opt/lucee/tomcat/lucee-server/context/password.txt
hit enter
systemctl start lucee
if lucee is working, then you can add
systemctl enable lucee
Thanks for the super detailed response. For the future: I’ve been using vi since the '80s, you can save some typing. 
I think the problem is less about the environment not being populated with JAVA_HOME, because even when I exported JAVA_HOME, the result was that catalina.sh was looking for /opt/lucee/jre/bin/java, when it didn’t install it. I’m guessing the installer sets “JAVA_HOME=/opt/lucee/jre”, whether it has installed the bundled JRE or not.
Ah, here is an instance, line 193 of lucee-installer/lucee/linux/sys/change_user.sh:
TEMP=`echo "JAVA_HOME=${myInstallDir}/jre; export JAVA_HOME" >> $TomcatControlScript`;
lucee_ctl is explicitly setting the JAVA_HOME whether one exists in the OS environment or not, and whether the installer has installed a JRE to that location. This is a bug in the installer.
I also see it doing something similar with the service.bat file for “@@luceeJREhome@@”.
But I’m not finding how “JAVA_HOME” or “JRE_HOME” is being set to “/opt/lucee/jre” in the installer, which is the logical assumption if I “export JAVA_HOME=/usr/lib/jvm/default-jvm” and then run the installer, and the installer runs catalina.sh and it fails saying “/opt/lucee/jre/bin/java not found”.
Clearly, you have strong feelings about Ubuntu. I’m willing to help make the Lucee installer work with Ubuntu, which can probably be done without sacrificing other environments, but I could use some help beyond “Use another distro”. If you want to actively make sure it doesn’t work on Ubuntu, please let me know and I’ll be on my way.
Your mention above leads me to LDEV-3832, which looks to be exactly the change that is the source of the problem I’m running into. I’ll see if I can look into the associated changes and come up with a fix. Thanks!
cool! I’m going to build the installers for 5.3.9.166 tomorrow, would be good to see if we can solve this problem.
I think one thing that definitely needs to change is the templating of lucee_ctl, as I mentioned above it is setting the JRE_HOME in line 192 of “lucee/linux/sys/change_user.sh”:
TEMP=`echo "JRE_HOME=${myInstallDir}/jre; export JRE_HOME" >> $TomcatControlScript`;
TEMP=`echo "JAVA_HOME=${myInstallDir}/jre; export JAVA_HOME" >> $TomcatControlScript`;
Maybe that needs to be templated similarly to the startup.bat?
Also, I think in “lucee/lucee.xml”, the line that reads “{installjre}” needs to have a “$” in it before the open brace: “${installjre}”.
I ran the GUI installer, and it showed me that it’d be installing using “/usr/bin/java” if I didn’t use the bundled version. The install.log says it started lucee:
Configuring Tomcat
Starting Lucee Service
Executing /opt/lucee/lucee_ctl start
Script exit code: 0
Script output:
* Starting Lucee: Tomcat started.
. . . [DONE]
But then it failed with:
Problem running post-install step. Installation may not complete correctly
Error setting passwords for Lucee admins. (did the service start?)
The GUI installer said it timed out waiting for tomcat (IIRC). I’m wondering if that’s because the lucee_ctl has the “/opt/lucee/jre” path in it for JRE_HOME and JAVA_HOME?
Normally, I’m running the installer like: “lucee-installer --mode unattended --luceepass LUCEEPASS”. It’s not clear to me what java_executable and java_version it is picking up there. I would assume it’s the same as the GUI, but is there any way I can verify?
Thanks
(also, let me know if it would be more useful to have the discussion in LDEV-3832, I can’t update that ticket, but I have a Jira account if it would be useful to work in the ticket.)
happy to discuss here!
I went and updated the install builder xml file, but it’s not updating the change_user.sh script
Higher up in the builder.xml there is an OS DETECT, which right now generically finds “linux” and does what every other distro needs to install.
Either the build could be forked for just “ubuntu” or the script needs a new way of detecting the environment before applying the final build script parameters to make the lucee_cntrl file.
It may take a month, as my “free time” has taken a serious hit as of late.
I looked at your change, and it looks reasonable. I don’t understand what you mean by “it’s not updating the change_user.sh”, it looks like the changes you made should be modifying it. Are you saying “I put changes in but it’s not working”, or are you saying “there is work yet to be done”?
I’m still working on wrapping my head around installbuilder, so I’m afraid I’m of limited help right now, but let me know if there’s anything I can do. I know you’re planning on building installers soon, but I’m hoping Monday to spend some time learning installbuilder and seeing if I can build a test version to run some trials with.
From what I saw running the GUI installer, it is correctly detecting “/usr/bin/java” as the java executable. So we have that at least. As I understand it, the code we’re talking about is: <dirName path="${java_bin_dir}" variable="java_home_dir"/>
I have a few options for other ways to set java_home_dir, though I’m not exactly sure how to express them in InstallBuilder yet. My thoughts:
dirname $(dirname $(readlink -f ${java_bin_dir}/java))
/usr/lib/jvm/default-java exists, use that as the java_home_dir, otherwise use the current value. This doesn’t account for updating /etc/alternatives though, so it’ll work but it is less optimal.Thoughts?
I am looking at the 5.x kernel and something at the commandline isnt being set correctly.
Even with SELINUX or App Armor off, the script fails to properly complete the install.
It just doesn’t want to GRAB the environment in text mode to pipe it back to the build script.
A work around could be to ask the user : what is your path to JAVA_HOME ? We think its /something/ What is your path to JRE_HOME, We think its …/ and or just creating a symlink to java_home so /lucee/jre/bin is really symlink to /path-to/java/
Asking the user, particularly if it can be provided via a command-line switch (I’m trying to run --mode unattended), would be perfectly reasonable for my use case.