Getting artifactory running on Ubuntu 18.04

I was trying to get the Artifactory OSS 6.3.3 running on Ubuntu 18.04 and ran into issues described in RTFACT-16909. The issue is that there are systemd changes in 18.04 that make the handling of PID files much stricter. When Artifactory starts up as a service, systemd runs /opt/jfrog/artifactory/bin/artifactoryManage.sh as root. But the script then starts up Tomcat as the artifactory user. The PID of the Tomcat process is then written to the PID file in /var/opt/jfrog/run/artifactory.pid. When control comes back to systemd, it sees that the PID file is not owned by root and refuses to deal with it. The errors look like this:

Sep 26 19:04:33 ip-172-31-41-254 artifactoryManage.sh[13784]: Max number of open files: 1024
Sep 26 19:04:33 ip-172-31-41-254 artifactoryManage.sh[13784]: Using ARTIFACTORY_HOME: /var/opt/jfrog/artifactory
Sep 26 19:04:33 ip-172-31-41-254 artifactoryManage.sh[13784]: Using ARTIFACTORY_PID: /var/opt/jfrog/run/artifactory.pid
Sep 26 19:04:33 ip-172-31-41-254 artifactoryManage.sh[13784]: Tomcat started.
Sep 26 19:05:02 ip-172-31-41-254 systemd[1]: Started Session 211 of user ubuntu.
Sep 26 19:05:12 ip-172-31-41-254 artifactoryManage.sh[13784]: Artifactory Tomcat started in normal mode
Sep 26 19:05:12 ip-172-31-41-254 systemd[1]: artifactory.service: New main PID 13844 does not belong to service, and PID file is not owned by root. Refusing.
Sep 26 19:05:12 ip-172-31-41-254 systemd[1]: artifactory.service: New main PID 13844 does not belong to service, and PID file is not owned by root. Refusing.
Sep 26 19:05:12 ip-172-31-41-254 systemd[1]: artifactory.service: Failed with result 'protocol'.
Sep 26 19:05:12 ip-172-31-41-254 systemd[1]: Failed to start Setup Systemd script for Artifactory in Tomcat Servlet Engine.
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: artifactory.service: Service hold-off time over, scheduling restart.
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: artifactory.service: Scheduled restart job, restart counter is at 201.
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: Stopped Setup Systemd script for Artifactory in Tomcat Servlet Engine.
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: Starting Setup Systemd script for Artifactory in Tomcat Servlet Engine...
Sep 26 19:05:17 ip-172-31-41-254 artifactoryManage.sh[14254]: found java executable in JAVA_HOME
Sep 26 19:05:17 ip-172-31-41-254 artifactoryManage.sh[14254]: Artifactory Tomcat already started
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: artifactory.service: Can't open PID file /var/opt/jfrog/run/artifactory.pid (yet?) after start: No such file or directory
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: artifactory.service: Failed with result 'protocol'.
Sep 26 19:05:17 ip-172-31-41-254 systemd[1]: Failed to start Setup Systemd script for Artifactory in Tomcat Servlet Engine.
Sep 26 19:05:23 ip-172-31-41-254 systemd[1]: artifactory.service: Service hold-off time over, scheduling restart.
Sep 26 19:05:23 ip-172-31-41-254 systemd[1]: artifactory.service: Scheduled restart job, restart counter is at 202.
Sep 26 19:05:23 ip-172-31-41-254 systemd[1]: Stopped Setup Systemd script for Artifactory in Tomcat Servlet Engine.

To work around this issue, you have to do the following. First, in /lib/systemd/system/artifactory.service add the following lines under the [Service] section:

User=artifactory   # change if your artifactory user is different
Group=artifactory  # change if your artifactory group is different

This will now run artifactoryManage.sh as the artifactory user. But the script assumes that it is to be run as root, and so there are some changes you will need to make. First, the script uses ulimit to change the limits on the number of open files. This will fail because the artifactory user will not have permissions to set the hard limit. You can get around that by adding the following to /etc/security/limits.conf:

artifactory soft nofile 32000  # change if your artifactory user is different
artifactory hard nofile 32000  # change if your artifactory user is different

Note: The actual numbers may be different for your system. To find out what they are, manually run artifactoryManage.sh start as the artifactory user before you make the above changes. The script should spit out lines similar to the ones above.

Finally, you will need to change some lines in /opt/jfrog/artifactory/bin/artifactoryManage.sh. In the snippet below, the commented-out line is the code as it originally appears and the modification is just below that:

#su -s "/bin/sh" ${ARTIFACTORY_USER} -c "${replicatorScript} start"
${replicatorScript} start

...

#su -s "/bin/sh" ${ARTIFACTORY_USER} -c "${replicatorScript} start"
${replicatorScript} stop

...

#su -s "/bin/sh" $ARTIFACTORY_USER -c "export JAVA_HOME='$JAVA_HOME'; $TOMCAT_HOME/bin/startup.sh"
$TOMCAT_HOME/bin/startup.sh

...

#su -s "/bin/sh" $ARTIFACTORY_USER -c "export JAVA_HOME='$JAVA_HOME'; $TOMCAT_HOME/bin/shutdown.sh"
$TOMCAT_HOME/bin/shutdown.sh

Note: I also made these exact changes to /opt/jfrog/artifactory/misc/service/artifactory for the sake of consistency, but I have not verified that it is strictly necessary.

We have to make these changes because artifactoryManage.sh is being run as the artifactory user now and so there is no need to explicitly run the other scripts as the same user. Once you make these changes, you should be able to start artifactory via systemctl start artifactory.service successfully.