Troubleshooting Stage 1 - "service artifactory start" did not work

What to Do When Your Artifactory Upgrade Fails

AuthorFullName__c
Patrick Russell
articleNumber
000004543
ft:sourceType
Salesforce
FirstPublishedDate
2019-10-02T07:13:57Z
lastModifiedDate
2024-03-10T07:46:09Z
VersionNumber
7
If you see a Systemd error when trying to start Artifactory, first make sure this is a real error. Sometimes an upgrade will cause your Linux Systemd to report an error when the Tomcat server started anyway:
 
sudo systemctl start artifactory
Job for artifactory.service failed because the control process exited with error code.
See "systemctl status artifactory.service" and "journalctl -xe" for details.
Check for the exact reason via the recommended journalctl -xe command. Running both of the commands above and reviewing the output(s) produced may indicate a clear error, such as a Linux permission problem.

You can also try checking for the presence of your Java/Artifactory PID:

ps aux | grep artifactory

[Expected output on a running Artifactory]
User-added image

If the PID is not present, then there's likely a problem with your service installation (Artifactory Systemd scripts). If yours is a Zip installation, try rerunning the $ART_HOME/bin/installService.sh script.

If none of the steps above help (or yours is an RPM or Debian installation), the problem has been identified as a systemD error. You can can bypass the systemD to continue the upgrade. To proceed, you'll want to manually start Artifactory by going to the bin folder (/opt/jfrog/artifactory/bin in RPM and Debian installations) and triggering the artifactoryManage.sh script:
./bin/artifactoryManage.sh start
+++ dirname ./bin/artifactoryManage.sh
++ cd ./bin
++ pwd
[... A lot of debug output is printed to standard out …]
+ '[' 1 -eq 0 ']'
+ echo 'Artifactory Tomcat started in normal mode'
Artifactory Tomcat started in normal mode
+ exit 0