We currently have Artifactory running on a Digital Ocean Droplet under Tomcat
Artifactory starts nice and quickly, but the deployment doesn't actually complete until it's done, I can't work out how to get any further information out from either the Artifactory Deployment or the Tomcat Server
2017-01-11 13:18:20,707 [art-init] [INFO ]
(o.a.w.s.ArtifactoryContextConfigListener:219) -
###########################################################
### Artifactory successfully started (14.442 seconds) ###
###########################################################
From the catalina.log
11-Jan-2017 13:18:00.921 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor Deploying configuration descriptor /opt/jfrog/artifactory/tomcat/conf/Catalina/localhost/artifactory.xml
11-Jan-2017 13:35:28.086 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of configuration descriptor /opt/jfrog/artifactory/tomcat/conf/Catalina/localhost/artifactory.xml has finished in 1,047,164 ms
I'm confused as to what's going on between 13:18:20 and 13:25:28, Artifactory doesn't have a forum anymore and directs everyone here.
Related
I'm in the process of upgrading and migrating Artifactory version 6.11 (zip install, housed on RH7) to the 7.35 version (housed on a new server and hostname, rpm install). I'm doing this on a cloned VM as a test, so the only thing that is different from our original system is the hostname. As the documentation recommends, I first upgraded 6.11 to 7.35 and everything seemed to go well. I followed the upgrade steps and the migration.sh script completed successfully.
The major issue I'm having is that when I go into Artifacts, the 'url to file' is bringing up a 502 Bad Gateway nginx error. It seems to me that a pointer is incorrect somewhere and I'm confused as to where it could be. The upgrade was successful, so I know the data is there, but Artifactory is not able to link to it properly.
Update/clarification: To improve my description: When I head into Application bar / Artifactory / Artifacts and select a repo from the left-hand column, the 'url to file' fails to load. I'm assuming this is the tree view?
On the server that is currently working, a url such as https://acme/artifactory/repo leads to a directory listing. However, on the new server, a url such as https://new-acme-server/artifactory/repo would lead to a 502 Bad Gateway or an nginx error if I use http (no cert is installed on the test VM, but is installed on the orignal server).
In v7.35, I went into the 'http settings' and switched the server provider as both nginx and apache (Tomcat was set as default) and while the site operated fine under both, the url to the repo files still fails with an nginx error, regardless of the server provider.
When I did a full system export of the original server, the documentation had me uncheck "Exclude data". I also exported the repos out as well and imported those in via a path. Everything seems to show up correctly just like on the original server, but I'm still unable to view a directory listing when I click on the url.
Could it be the location of the filestore being different? If so, how would I go about pointing it to the right location?
V7.35: /opt/jfrog/artifactory/var/data/artifactory/filestore
V6.11: /opt/artifactory/artifactory-pro-6.11.3/data/filestore
The base URL is the same as the original installation http(s)://domain/artifactory
Output from artifactory-service.log
2022-03-25T16:58:40.429Z [jfrt ] [INFO ] [3bb67ba1f30d560e] [ifactoryApplicationContext:564] [ttp-nio-8081-exec-10] - Artifactory application context set to READY by reload
2022-03-25T16:58:40.430Z [jfrt ] [INFO ] [3bb67ba1f30d560e] [c.CentralConfigServiceImpl:933] [ttp-nio-8081-exec-10] - Configuration reloaded.
2022-03-25T17:09:04.013Z [jfrt ] [INFO ] [708a8ae7c307ec92] [c.CentralConfigServiceImpl:914] [http-nio-8081-exec-5] - Reloading configuration... old revision 212, new revision 213
2022-03-25T17:09:04.121Z [jfrt ] [INFO ] [708a8ae7c307ec92] [c.CentralConfigServiceImpl:542] [http-nio-8081-exec-5] - New configuration with revision 213 saved.
2022-03-25T17:09:04.121Z [jfrt ] [INFO ] [708a8ae7c307ec92] [ifactoryApplicationContext:564] [http-nio-8081-exec-5] - Artifactory application context set to NOT READY by reload
2022-03-25T17:09:04.181Z [jfrt ] [INFO ] [708a8ae7c307ec92] [ifactoryApplicationContext:564] [http-nio-8081-exec-5] - Artifactory application context set to READY by reload
2022-03-25T17:09:04.181Z [jfrt ] [INFO ] [708a8ae7c307ec92] [c.CentralConfigServiceImpl:933] [http-nio-8081-exec-5] - Configuration reloaded.
2022-03-25T17:36:47.707Z [jfrt ] [INFO ] [d7bb51eedd93b03c] [aseBundleCleanupServiceImpl:84] [art-exec-20 ] - Starting to cleanup incomplete Release Bundles
2022-03-25T17:36:47.708Z [jfrt ] [INFO ] [d7bb51eedd93b03c] [b.ReleaseBundleServiceImpl:415] [art-exec-20 ] - Finished deleting orphan/unidentified items from _intransit repository
2022-03-25T17:36:47.709Z [jfrt ] [INFO ] [d7bb51eedd93b03c] [aseBundleCleanupServiceImpl:90] [art-exec-20 ] - Finished incomplete Release Bundles cleanup
Your filestore location for both Artifactory 6 and Artifactory7 is correct.
This indicates to me that the issue is with your reverse proxy.
In order to confirm, can you check the below two things.
Open your Artifactory on its IP and Port.
http://localhost:8082/ (The default port will be 8082 if you have not modified). Now go to tree view in Application tab of Artifactory and try to download a specific file. If you are able to download, then the issue is might not be with filestore or upgrade. Mostly it should be reverse proxy.
In that case, navigate to Artifactory > Administration > Artifactory > HTTP Settings > Genereate new settings > Place in reverse proxy and restart.
In the above test, if you are still not able to download, then check in the logs ($JFROG_HOME/artifactory/var/log/artifactory-service.log) if you are observing a message something similar to the below.
2022-03-24T20:15:35.072Z [jfrt ] [WARN ] [2a73d62655afd1ad] [.r.ArtifactoryResponseBase:136] [http-nio-8081-exec-9] - Sending HTTP error code 500: Could not process download request: Binary provider has no content for '165c79f8dff2f9e7d3ccadcbc295f7ef8e6e95f0'
If yes, then it indicates that, Artifactory is not able to find the binary. If none of the above helped, post the log snippet from the above log file here while you are trying to download a file along with the file name.
For your update/clarification questions, please allow me to clarify.
In Artifactory 6.x Artifactory was acting as both the server and UI, therefore you could use the "http://acme/artifactory URL, however in Artifactory 7.x, Artifactory changed to work with multiple microservices, and the UI has moved to its own microservice (now it is named "Frontend"). You can try access the "Native Browser" by using this URL http://acme/ui/native/REPOSITORY/.
To add to the above and to Ganapathi's reply, the URL for your Artifactory has changed from http://acme:8081/artifactory to http://acme:8082 since Artifactory is now utilizing the "router" (external port is 8082 and internal 8046) microservice to redirect all the requests to the respective microservices. You can check the full list here.
I hope this clarifies more.
What reasons could there be that a push of a docker image to an Artifactory repo could crash the entire app?
The symptoms I see are that a layer hangs during the push:
ยป docker push my-repo/my-app:20211207-afdf6438-test
The push refers to repository [my-repo/my-app]
d4cde41bcf33: Layer already exists
ac14050b2264: Layer already exists
27e5cc646fd0: Pushing [==================================================>] 562.7MB
797b1ec2507f: Layer already exists
34de87854e34: Layer already exists
cde140fcdbee: Layer already exists
be3883e87d34: Layer already exists
9ec86c039eae: Layer already exists
371ce8b24b31: Layer already exists
7e718b9c0c8c: Layer already exists
It hangs on pushing that layer, then Artifactory becomes unresponsive until it finally restarts itself, which takes a while.
When this happens, the logs don't give me much to go on.
2021-12-09T20:06:01.066Z [jfrt ] [INFO ] [44ac995c9c11dc2e] [o.a.e.UploadServiceImpl:465 ] [http-nio-8081-exec-2] - Deploy to 'docker-local:my-app/_uploads/60766841-fac7-4781-b325-da9ef66ba2cf' Content-Length: 1 (estimation) artificial: false
2021-12-09T20:06:27.249Z [jfrt ] [INFO ] [ ] [ffectedConfigStreamObserver:32] [Stream_1639080147248] - publishing full invalidation and attempting to resubscribe to affected configuration changes
2021-12-09T20:06:28.145Z [jfrt ] [INFO ] [ ] [ffectedConfigStreamObserver:32] [Stream_1639080153144] - publishing full invalidation and attempting to resubscribe to affected configuration changes
2021-12-09T20:06:29.646Z [jfrt ] [INFO ] [ ] [ectedEntitiesStreamObserver:35] [Stream_1639080154645] - publishing full invalidation and attempting to resubscribe to affected permissions changes
2021-12-09T20:07:26.615Z [jfrt ] [ERROR] [59398681a5a1be14] [o.j.a.c.h.AccessHttpClient:136] [http-nio-8081-exec-6] - Error while executing /api/v1/users/ on access. Exception message: Read timed out
2021-12-09T20:07:51.686Z [jfrt ] [ERROR] [6a934e4bf3e126b4] [o.j.a.c.h.AccessHttpClient:136] [http-nio-8081-exec-4] - Error while executing /api/v1/users/ on access. Exception message: Read timed out
2021-12-09T20:07:56.622Z [jfrt ] [ERROR] [2fe4c5688866ed57] [o.j.a.c.h.AccessHttpClient:136] [http-nio-8081-exec-8] - Error while executing /api/v1/users/ on access. Exception message: Read timed out
2021-12-09T20:07:56.622Z [jfrt ] [ERROR] [2b94004eb23bb041] [o.j.a.c.h.AccessHttpClient:136] [ttp-nio-8081-exec-12] - Error while executing /api/v1/users/ on access. Exception message: Read timed out
Terminating Artifactory
This is self-hosted Artifactory 7.27.10 running in Kubernetes
This was a disk performance problem. I use EFS for my Artifactory data volume. For some reason still unknown to me, Artifactory started requiring higher IOPS than the EFS volume could provide. I was able to solve the problem by changing the EFS volume to provisioned IOPS.
Pulls worked fine, because my backing datastore is s3. So the problem only manifested on pushes, after all the docker layers were uploaded, and when log files were written to the EFS volume. It was on log writes that the system choked and restarted.
I'm currently trying to setup Bitnami's Wordpress + Nginx Docker with Azure App Service for Containers and I am stuck at the error message: Stopping site because it failed during startup.
I already tried to increase WEBSITES_CONTAINER_START_TIME_LIMIT without success. I also tried to find anything in the other logs, however, there is not relevant information.
This is my log:
2021-03-26T20:26:39.850Z INFO - Starting multi-container app..
2021-03-26T20:26:40.686Z INFO - Pulling image from Docker hub: registry.hub.docker.com/bitnami/wordpress-nginx
2021-03-26T20:26:42.009Z INFO - latest Pulling from bitnami/wordpress-nginx
2021-03-26T20:26:42.011Z INFO - Digest: sha256:08ea17712bc6cd31a20128557aa5bbad562dc81af2e9a26b4f45bfca40e5538c
2021-03-26T20:26:42.013Z INFO - Status: Image is up to date for registry.hub.docker.com/bitnami/wordpress-nginx:latest
2021-03-26T20:26:42.021Z INFO - Pull Image successful, Time taken: 0 Minutes and 1 Seconds
2021-03-26T20:26:42.050Z INFO - Starting container for site
2021-03-26T20:26:42.052Z INFO - docker run -d -p 9180:80 --name as-wp-weu-prod_wordpress_0_f1793421 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=true -e WEBSITE_SITE_NAME=as-wp-weu-prod -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=as-wp-weu-prod.azurewebsites.net -e WEBSITE_INSTANCE_ID=8d9749e1ad54987267d51cda41194309f78e9fe336b09f44ea04d81342bdd40c -e HTTP_LOGGING_ENABLED=1 registry.hub.docker.com/bitnami/wordpress-nginx
2021-03-26T20:56:42.520Z ERROR - multi-container unit was not started successfully
2021-03-26T20:56:42.546Z INFO - Container logs from as-wp-weu-prod_wordpress_0_f1793421 = 2021-03-26T20:26:49.138042862Z [0m
2021-03-26T20:26:49.138217863Z [0m[1mWelcome to the Bitnami wordpress-nginx container[0m
2021-03-26T20:26:49.138376864Z [0mSubscribe to project updates by watching [1mhttps://github.com/bitnami/bitnami-docker-wordpress-nginx[0m
2021-03-26T20:26:49.138532065Z [0mSubmit issues and feature requests at [1mhttps://github.com/bitnami/bitnami-docker-wordpress-nginx/issues[0m
2021-03-26T20:26:49.147750834Z [0m
2021-03-26T20:26:56.839294655Z nami INFO Initializing php
2021-03-26T20:26:56.907101461Z nami INFO php successfully initialized
2021-03-26T20:27:04.576803980Z nami INFO Initializing nginx
2021-03-26T20:27:04.676840017Z nami INFO nginx successfully initialized
2021-03-26T20:27:12.622656961Z nami INFO Initializing mysql-client
2021-03-26T20:27:12.721293503Z nami INFO mysql-client successfully initialized
2021-03-26T20:27:22.196788004Z nami INFO Initializing wordpress
2021-03-26T20:27:22.519271584Z wordpre INFO ==> Preparing Varnish environment
2021-03-26T20:27:22.527241945Z wordpre INFO ==> Preparing Apache environment
2021-03-26T20:27:22.537316623Z wordpre INFO ==> Preparing PHP environment
2021-03-26T20:27:22.588082613Z wordpre INFO WordPress has been already initialized, restoring...
2021-03-26T20:27:24.832051104Z mysql-c INFO Trying to connect to MySQL server
2021-03-26T20:27:24.861626532Z mysql-c INFO Found MySQL server listening at mariadb-weu-prod.mariadb.database.azure.com:3306
2021-03-26T20:27:25.130808807Z mysql-c INFO MySQL server listening and working at mariadb-weu-prod.mariadb.database.azure.com:3306
2021-03-26T20:27:25.130828007Z wordpre INFO Upgrading WordPress Database ...
2021-03-26T20:27:27.133719647Z wordpre INFO
2021-03-26T20:27:27.134393052Z wordpre INFO ########################################################################
2021-03-26T20:27:27.135004057Z wordpre INFO Installation parameters for wordpress:
2021-03-26T20:27:27.141716808Z wordpre INFO Persisted data and properties have been restored.
2021-03-26T20:27:27.142344313Z wordpre INFO Any input specified will not take effect.
2021-03-26T20:27:27.142926818Z wordpre INFO This installation requires no credentials.
2021-03-26T20:27:27.143452822Z wordpre INFO ########################################################################
2021-03-26T20:27:27.143975626Z wordpre INFO
2021-03-26T20:27:27.144505830Z nami INFO wordpress successfully initialized
2021-03-26T20:27:27.205315299Z [0m[38;5;2mINFO [0m ==> Starting gosu...
2021-03-26T20:27:27.243704595Z [0m[38;5;2mINFO [0m ==> Starting PHP-FPM...
2021-03-26T20:27:27.245663910Z [0m[38;5;2mINFO [0m ==> Starting NGINX...
2021-03-26T20:27:27.335050999Z 2021/03/26 20:27:27 [warn] 83#83: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/bitnami/nginx/conf/nginx.conf:2
2021-03-26T20:27:27.335712104Z nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/bitnami/nginx/conf/nginx.conf:2
2021-03-26T20:56:46.234Z INFO - Stopping site as-wp-weu-prod because it failed during startup
This is my docker-compose:
version: '3.9'
services:
wordpress:
image: registry.hub.docker.com/bitnami/wordpress-nginx
restart: always
ports:
- '8080:80'
volumes:
- ${WEBAPP_STORAGE_HOME}/site/wwwroot:/bitnami/wordpress
- ${WEBAPP_STORAGE_HOME}/site/server_blocks:/opt/bitnami/nginx/conf/server_blocks/wordpress-server-block.conf
Thank you!
I am trying to deploy shiny server pro on a ubuntu 19.04 machine. I opted for the 45 days evaluation period where in Rstudio provides unrestricted access to shiny server pro features for the said period. But after setting up the server, I found out in the logs that my evaluation period had expired just after one day of use.
For setting up the server I followed the following steps:
Entered my details in the evaluation period form in this link https://rstudio.com/products/shiny-server-pro/evaluation/
I received a link in my mail which took me to the page which contains the commands to set up the R shiny pro server in ubuntu. This can be found here https://rstudio.com/products/shiny/download-commercial/ubuntu/
After following the steps,and changing the run_as parameter to my username in shiny-server.conf file I was able to get the server running. But found this in the logs:
[2019-10-15T14:05:28.424] [INFO] shiny-server - Shiny Server Pro v1.5.12.1023 (Node.js v10.15.3)
[2019-10-15T14:05:28.426] [INFO] shiny-server - Using config file "/etc/shiny-server/shiny-server.conf"
[2019-10-15T14:05:28.427] [INFO] shiny-server - Using non-persistent random cookie secret
[2019-10-15T14:05:28.467] [INFO] shiny-server - No authentication system configured.
[2019-10-15T14:05:28.469] [INFO] shiny-server - Starting listener on http://[::]:3838
[2019-10-15T14:05:28.478] [INFO] shiny-server - License type: traditional
[2019-10-15T14:05:28.539] [INFO] shiny-server - Licensing check succeeded.
[2019-10-15T14:05:28.541] [ERROR] shiny-server - Your evaluation has ended. Please activate!
I tried the same steps on an EC2 instance, but ran into the same problem.
for anyone facing a similar issue kindly note that I was able to resolve the above error by raising a ticket to Rstudio who acknowledged the same and were kind enough to provide me with a new trial period key
Since upgrading to 6.8.7 using the rpm on RHEL 7, using systemctl start artifactory fails
Looking in the log its failing at this point
2019-03-16 09:50:28,952 [art-init] [INFO ] (o.a.s.a.ArtifactoryAccessClientConfigStore:593) - Using Access Server URL: http://localhost:8040/access (bundled) source: detected
2019-03-16 09:50:29,379 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:353) - Waiting for access server...
2019-03-16 09:50:30,625 [art-init] [WARN ] (o.j.a.c.AccessClientHttpException:41) - Unrecognized ErrorsModel by Access. Original message: Failed on executing /api/v1/system/ping, with response: Not Found
2019-03-16 09:50:30,634 [art-init] [ERROR] (o.a.s.a.AccessServiceImpl:364) - Could not ping access server: {}
org.jfrog.access.client.AccessClientHttpException: HTTP response status 404:Failed on executing /api/v1/system/ping, with response: Not Found
Previously we would get
2019-03-13 09:56:06,293 [art-init] [INFO ] (o.a.s.a.ArtifactoryAccessClientConfigStore:593) - Using Access Server URL: http://localhost:8040/access (bundled) source: detected
2019-03-13 09:56:06,787 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:353) - Waiting for access server...
2019-03-13 09:56:24,068 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:360) - Got response from Access server after 17280 ms, continuing.
Any suggestions on debugging whether this access server has started ?
Further to this I found logs showing when it worked it used to start a jar file
2019-03-08 09:19:11,609 [localhost-startStop-2] [INFO ] (o.j.a.AccessApplication:48) - Starting AccessApplication v4.1.48 on hostname.nexor.co.uk with PID 5913 (/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-application-4.1.48.jar started by artifactory in /)
Now when i look I find /opt/jfrog/artifactory/tomcat/webapps/access/ is empty so there is no jar file to run
The rpm did deliver an access.war file and that is there
$ ls -l /opt/jfrog/artifactory/webapps
total 104692
-rwxrwxr-x. 1 root root 51099759 Mar 14 12:14 access.war
-rwxrwxr-x. 1 root root 56099348 Mar 14 12:14 artifactory.war
Is there some manual step I can run to expand this war file to get the jar (as you can guess I am not up on my java apps)
Eventually got it working by deleting the empty /opt/jfrog/artifactory/tomcat/webapps/access directory and a new one containing the required jar files got created.
Not sure why this happened but that got it working for me
I had similar problem on CentOS 7, the solution was downgrade the newly updated java packages by running this command:
yum downgrade java-1.8.0*
After that restart the artifactory:
systemctl restart artifactory
Try changing the port number under your tomcat\conf\server.xml from 8081 to a different, unused port. Then, restart the Artifactory service to ensure the change takes effect.