[Spacewalk-list] Spacewalk 2.7 - post upgrade. Taskomatic bunches/queues not processing?
Kalchik, Jeffery
JDKalchik at landolakes.com
Fri Dec 15 19:02:52 UTC 2017
Good afternoon, all.
And, as is frequently the case, I'll struggle with something for several days, finally ask for assistance..... and solve it myself within a couple of hours.
The secret appears to be in execution of taskomatic. reinitializeAllSchedulesFromNow. I don't know what's caused the log jam, but simply executing this:
my $RC = $CLIENT->call('taskomatic.reinitializeAllSchedulesFromNow', $SESSION);
printf("%s\n", Dumper($RC));
now shows a lot of expected Taskomatic activity. Time will tell, but the channel-repo-data bunch immediately fired off, which is the one I've been most concerned with.
Now.......for a bit of a nit to pick. For years, I've been using Perl scripts for some task automation, and used the API docs to write these scripts. I've been redirected to:
https://spacewalkproject.github.io/documentation/api/2.7/index.html
for the 2.7 API documentation. However, the taskomatic and taskomatic.org namespace APIs are conspicuous by their absence. I've found those here:
https://github.com/spacewalkproject/spacewalk/wiki/Features_TaskomaticAPI
Should the taskomatic and taskomatic.org namespaces be included in the main API docs?
Jeff Kalchik
Systems Engineering
Land O'Lakes
651-375-2421
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Kalchik, Jeffery
Sent: Friday, December 15, 2017 7:15 AM
To: spacewalk-list at redhat.com
Subject: [Spacewalk-list] Spacewalk 2.7 - post upgrade. Taskomatic bunches/queues not processing?
This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>
Feedback<http://aka.ms/SafetyTipsFeedback>
Good morning, all.
Sunday, I finally upgraded from 2.6 to 2. (CentOS6 host, 2vCPUs and 12gb of RAM.) Since then, I have discovered a little Taskomatic tweaking is in order, max heap size has been increased to 2gb. The upgrade itself was largely uneventful, had to remove xmlbeans, manually swap jpackage-tools out for javapackage-tools, and create the symlink for the geronimo-jta.jar -> jta.jar issue (referenced for RHEL6, but not CentOS6.)
Unfortunately, I've discovered since, that I've got problems with Taskomatic bunches not processing on time:
Last Execution Times
Last Execution Times
Auto Errata Updates: 2017-12-10 10:55:00 CST FINISHED
Channel Repodata: 2017-12-13 14:21:01 CST INTERRUPTED
Changelog Cleanup: 2017-12-14 23:00:00 CST FINISHED
Clean Log History: 2017-12-14 23:00:00 CST FINISHED
Cobbler Sync: 2017-12-10 11:21:32 CST FINISHED
Compare Config Files: 2017-12-14 23:00:00 CST FINISHED
Daily Summary Mail: 2017-12-14 23:00:00 CST FINISHED
Errata Cache: 2017-12-10 11:00:00 CST FINISHED
Errata Notification Mail: 2017-12-10 11:00:00 CST FINISHED
Errata Notification Queue: 2017-12-10 11:00:00 CST FINISHED
Kickstart Cleanup: 2017-12-10 11:00:00 CST FINISHED
Kickstart Sync: 2017-12-10 11:21:33 CST FINISHED
Package Cleanup: 2017-12-12 15:06:44 CST FINISHED
Failed reboots cleanup: 2017-12-15 07:00:00 CST FINISHED
Sandbox Cleanup: 2017-12-15 04:05:00 CST FINISHED
Session Cleanup: 2017-12-13 15:13:18 CST FINISHED
Daily Summary Queue: 2017-12-14 23:00:00 CST FINISHED
UUID cleanup: 2017-12-15 07:00:00 CST FINISHED
The task schedules have been left bone-stock:
Schedule name Frequency Active From Bunch
auto-errata-default 0 5/10 * * * ? 2017-12-10 11:21:32 CST auto-errata-bunch
channel-repodata-default 0 * * * * ? 2017-12-10 11:21:32 CST channel-repodata-bunch
cleanup-data-default 0 0 23 ? * * 2012-09-26 16:27:16 CDT cleanup-data-bunch
clear-taskologs-default 0 0 23 ? * * 2012-09-26 16:27:16 CDT clear-taskologs-bunch
cobbler-sync-default 0 * * * * ? 2017-12-06 12:56:47 CST cobbler-sync-bunch
compare-configs-default 0 0 23 ? * * 2012-09-26 16:27:16 CDT compare-configs-bunch
daily-status-default 0 0 23 ? * * 2012-09-26 16:27:16 CDT daily-status-bunch
errata-cache-default 0 * * * * ? 2017-12-10 11:21:32 CST errata-cache-bunch
errata-queue-default 0 * * * * ? 2017-12-10 11:21:32 CST errata-queue-bunch
kickstart-cleanup-default 0 0/10 * * * ? 2017-12-10 11:21:32 CST kickstart-cleanup-bunch
kickstartfile-sync-default 0 0/10 * * * ? 2017-12-06 12:56:47 CST kickstartfile-sync-bunch
package-cleanup-default 0 0/10 * * * ? 2017-12-10 11:21:32 CST package-cleanup-bunch
reboot-action-cleanup-default 0 0 * * * ? 2017-12-10 12:09:55 CST reboot-action-cleanup-bunch
sandbox-cleanup-default 0 5 4 ? * * 2012-09-26 16:27:16 CDT sandbox-cleanup-bunch
session-cleanup-default 0 0/15 * * * ? 2017-12-10 11:21:32 CST session-cleanup-bunch
uuid-cleanup-default 0 0 * * * ? 2017-12-10 12:09:55 CST uuid-cleanup-bunch
All of the services appear to be up:
$ sudo spacewalk-service status
postmaster (pid 51627) is running...
router (pid 51664) is running...
sm (pid 51672) is running...
c2s (pid 51680) is running...
s2s (pid 51688) is running...
tomcat6 (pid 51766) is running... [ OK ]
httpd (pid 51888) is running...
osa-dispatcher (pid 51916) is running...
rhn-search is running (51938).
cobblerd (pid 51981) is running...
RHN Taskomatic is running (52007).
All of the bunches dated 2017-12-10 have not executed since I upgraded on Sunday. They will execute if I run them manually through the single run scheduler, but not otherwise. Obviously, this is having some rather wide ranging side effects. I've never had to get into Taskomatic much over the years, I really don't grok how it works under the covers.
I'd really much rather not have to go back to a 2.6 image. Any idea what I have manage to foul up during the upgrade process?
Jeff Kalchik
Systems Engineering
Land O'Lakes
651-375-2421
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20171215/5804d398/attachment.htm>
More information about the Spacewalk-list
mailing list