Artifactory Pro 7.33.12 Running on SLES 12-SP5
I did not configure the Replicator in system.yaml or somewhere else.
After restart from Artifactory always appears in console.log (No problem. Message exists since installing Artifactory last year):
2022-04-26T10:47:12... [.c.r.ReplicatorServiceImpl:119] [art-init- initializing Replicator Service
2022-04-26T10:47:12..[c.r.ReplicatorServiceImpl:338] [art-init] - Local Replicator is setting up in non-bundled mode
But suddenly appearing messages by restarting Artifactory:
Info: Replicator is starting
Replicator configured successfully
Replicator Version:release/20220124145455-preRelease-jfpdn-7-30-x-rc.1
Supporting mime-type: application/java-archive
Supporting mime-type: application/x-nupkg
Supporting mime-type: application/x-tar
Supporting mime-type: application/zip
registering profiling endpoints:localhost:8041
Initializing internal http client
replicator service id:jfxfer#01fdsky4nnnd301nzwzzey1cb4
Using Artifactory Blob Store in address: http://localhost:8046/artifactory
Replicator listening on localhost:8048
And every minute:
Initializing Replicator registration
url: http://localhost:8046/artifactory/api/replicator/register
token: eyJ2ZXIiOi****
Replicator registration request was forbidden (make sure Enterprise Plus license installed)
$JFROG_HOME/artifactory/app/replicator/bin/replicator.sh status
Replicator is not running
ps -eaf|grep replicator
artifac+ 17911 1 0 15:21 ? 00:00:00 $JFROG_HOME/artifactory/app/replicator/bin/jf-replicator --replicatorHome=$JFROG_HOME/artifactory/app/replicator
To kill the process is no good idea.
Every 5 seconds appears:
Readiness test failed with the following error: "required node services are missing or unhealthy"
The insert in system.yaml
## REPLICATOR TEMPLATE
replicator:
## Set to true if using an Enterprise Plus license
enabled: false
#port: 8048
has no effect.
What happened and how to stop the Replicator?
Does anyone have an answer?
Related
I have installed on Fedora 35 jfrog-artifactory-oss (v7.31.11-73111900.x86_64) and enabled it as a system service to start at boot. But whenever I boot up my OS, the server never starts properly. I will always need to kill the PID of the active running Artifactory process. If I then do sudo service artifactory restart it will bring up the server cleanly and everything is good. How can I avoid having to do this little dance? Is there something about OS boot up that is causing Artifactory to get thrown off?
I have looked at console.log when the server is not running properly after bootup, I see some logs like:
2022-01-27T08:35:38.383Z [shell] [INFO] [] [artifactoryManage.sh:69] [main] - Artifactory Tomcat already started
2022-01-27T08:35:43.084Z [jfac] [WARN] [d84d2d549b318495] [o.j.c.ExecutionUtils:165] [pool-9-thread-2] - Retry 900 Elapsed 7.56 minutes failed: Registration with router on URL http://localhost:8046 failed with error: UNAVAILABLE: io exception. Trying again
That shows that the server is not running properly, but doesn't give a clear idea of what to try next. Any suggestions?
2 things to check,
How is the artifactory.service file in the systemd directory
Whenever the OS is rebooted, what is the error seen in the logs, check all the logs.
Hint: From the warning shared, it seems that Router service is not able to start when OS is rebooted, so whenever OS is rebooted and issue comes up check the router-service.log for any errors/warnings.
I am new to Openstack. I installed Openstack using Packstack in my CentOS machine. When I try to login using the default keystone_admin credentials, it showed a server error.
Here is my keystone.log file. Can somebody help?
2020-05-07 03:13:57.097 2303 WARNING keystone.server.flask.application [req-8c75dc88-73f3-4605-8a6b-3ba515d9fd84 3a3280ddae08412ab1145c193b587161 - - default -] Authorization failed. The request you have made requires authentication. from 192.168.225.30: Unauthorized: The request you have made requires authentication.
2020-05-07 03:13:57.235 2300 WARNING keystone.common.rbac_enforcer.enforcer [req-d1a5e980-617f-48d4-8322-40b0aa068140 3a3280ddae08412ab1145c193b587161 - - default -] Deprecated policy rules found. Use oslopolicy-policy-generator and oslopolicy-policy-upgrade to detect and resolve deprecated policies in your configuration.
Link to picture
try to find any rc files in your /root folder.
the file name is similar with openrc or adminrc
$ .openrc
$ try some openstack command
and it will succeed.
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.
I install ROS on my server, but when I called ros start and it will running at my server, here is the log:
login as: root
root#*.*.*.*'s password:
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-109-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service !
root#iZwz940pq66re8qvh8adzuZ:~# ros start
info: Loaded feature token capabilities=[Sync], expires=Wed Apr 19 2017 22:15:29 GMT+0800 (CST)
info: Realm Object Server version 2.5.1 is starting
info: [sync] Realm sync server started ([realm-core-4.0.4], [realm- sync-2.1.10])
info: [sync] Directory holding persistent state: /root/data/sync/user_data
info: [sync] Operating mode: master_with_no_slave
info: [sync] Log level: info
info: [sync] Download log compaction is enabled
info: [sync] Max download size: 131072 bytes
info: [sync] Listening on 127.0.0.1:35571 (sync protocol version 22)
info: Realm Object Server has started and is listening on http://0.0.0.0:9080
But when I entered the address in the browser, It told me that I could not connect.And I use Realm Studio to connect it also tell me that could not reach the server, did i forget something steps? Maybe my server's security policy forbide the port?
Per to the log description, Realm Object Server has started and is listening on http://0.0.0.0:9080.
Please ensure you've allowed TCP port 9080 in your ECS security group.
For detail steps, please refer the document
Add a security group rule
I'm trying to configure nginx service using chef but Im getting the error below.
Chef::Exceptions::Service
-------------------------
service[nginx]: unable to locate the init.d script!
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/xxx/recipes/default.rb
23: service 'nginx' do
24: supports :status => true, :restart => true, :reload => true
25: action :enable
26: end
27:
I can restart the service manually on the machine with
service nginx restart
Redirecting to /bin/systemctl restart nginx.service
How to restart nginx service via chef if Systemctl manage the nginx service ?
Should I also create init.d script ?
Thanks
To copy this down to an answer:
That would do it, that predates the automatic systemd support. I don't remember if we even included systemd support at all back then. Probably best to upgrade to at least the latest 11.x release, though really you should move to 12 by now
You can try adding provider Chef::Provider::Service::Systemd to your service resource and see if that works. If it doesn't, then you'll need to upgrade.