Actions
Incident #9522
closed
Authorisation service not working in DEV
Status:
Closed
Priority:
Urgent
Assignee:
_InfraScience Systems Engineer
Category:
-
Target version:
Start date:
Aug 21, 2017
Due date:
Aug 21, 2017
% Done:
100%
Estimated time:
Infrastructure:
Development
Description
it seems the Authorisation service not working in the development infrastructure
2017-08-21 10:40:05,799 ERROR o.g.p.t.SmartGearsPortalValve [http-bio-9090-exec-92,invoke:62][PORTAL] 234684384 [http-bio-9090-exec-92] ERROR org.gcube.portal.threadlocalexec.SmartGearsPortalValve - Something went wrong in generating token for massimiliano.assante in scope /gcube
java.lang.Exception: error contacting authorization service (error code is 500)
at org.gcube.common.authorization.client.proxy.DefaultAuthorizationProxy.resolveTokenByUserAndContext(DefaultAuthorizationProxy.java:139)
at org.gcube.portal.threadlocalexec.SmartGearsPortalValve.invoke(SmartGearsPortalValve.java:53)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThre
Updated by Andrea Dell'Amico over 7 years ago
- Status changed from New to Closed
There was more than one problem:
- The auth service failed to authenticate against postgresql (certificate problem, I'm investigating it)
- The logs generated by the error filled the disk
I removed the old logs and restarted both pgpool/postgres and the auth service
@lucio.lelii@isti.cnr.it if you want to stick with that log level you should change the logback configuration to rotate more aggressively. There are a lot of logs that go to the standard error and they should managed by log4j or logback, too.
Updated by Lucio Lelii over 7 years ago
I cannot find the logs on the standard error. Regarding the log level is fine with me to change it to WARN or ERROR.
Actions
