https://community.cloudera.com/t5/Support-Questions/Oozie-workflow-actions-fail-with-quot-response-from-timeline/m-p/237956#M199767 <P>@ <A rel="nofollow" href="https://community.hortonworks.com/users/112984/gpjalocha.html">Grzegorz Jałocha</A> I have solved the problem. </P><P>The solution I found to fix this is as follow:</P><OL><LI>Check your yarn logs (/var/log/hadoop-yarn/yarn/ on hdp) for anything clear to spot, for instance, not enough yarn memory (and then fix it if relevant),</LI><LI>Clean up hdfs ATS data as described on the <A href="https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.0.1/data-operating-system/content/remove_ats_hbase_before_switching_between_clusters.html">HDP docs,</A></LI><LI>Clean up zookeeper ATS data (the example here is for insecure clusters, you will probably have another znode for kerberised clusters): z<EM>ookeeper-client rmr /atsv2-hbase-unsecure</EM></LI><LI>Restart <STRONG>*all*</STRONG> YARN services,</LI><LI>Restart ambari server (we had a case where it looked like the alert was wrongly cached).</LI></OL><P><BR /></P><P>I refer to the link below ：</P><P><A rel="noopener noreferrer noopener noreferrer" href="https://thisdataguy.com/2019/01/11/ats-server-does-not-start/" target="_blank">https://thisdataguy.com/2019/01/11/ats-server-does-not-start/</A></P><P><BR /></P><P>You need to clean up the ats related data in HDFS and zk， And then restart it</P><P>I hope help you .</P><P><BR /></P> Fri, 19 Apr 2019 09:53:58 GMT bin_albin 2019-04-19T09:53:58Z