[Spacewalk-list] Taskomatic runs indefinitely without ever generating repodata

[Florence Savary]

Hello,

Since the solution provided by the link didn't work, I also tried to set
the taskomatic.initmemory and taskomatic.maxmemory in the rhn.conf file as
well (as in /usr/share/rhn/config-defaults/rhn_taskomatic_daemon.conf), but
it didn't work either.

In the logs, we have the following lines :

INFO   | jvm 1    | 2018/06/25 18:01:11 | 2018-06-25 18:01:11,191
[DefaultQuartzScheduler_Worker-1] DEBUG
com.redhat.rhn.taskomatic.task.ChannelRepodata - Starting run 3431420
INFO   | jvm 1    | 2018/06/25 18:01:11 | 2018-06-25 18:01:11,192
[DefaultQuartzScheduler_Worker-1] DEBUG
com.redhat.rhn.taskomatic.task.ChannelRepodata - Queue size (before run): 0
INFO   | jvm 1    | 2018/06/25 18:01:24 | 2018-06-25 18:01:24,245
[DefaultQuartzScheduler_Worker-1] INFO
com.redhat.rhn.taskomatic.task.ChannelRepodata - *In the queue: 127*
INFO   | jvm 1    | 2018/06/25 18:01:24 | 2018-06-25 18:01:24,379
[DefaultQuartzScheduler_Worker-1] DEBUG
com.redhat.rhn.taskomatic.task.ChannelRepodata - Creating
ChannelRepodataWorker with prefixPath(rhn/repodata), mountPoint(/var/cache)
for channel_label (cha-centos-6-x86_64-epel)
INFO   | jvm 1    | 2018/06/25 18:01:24 | 2018-06-25 18:01:24,379
[DefaultQuartzScheduler_Worker-1] DEBUG
com.redhat.rhn.taskomatic.task.ChannelRepodata - Putting worker
INFO   | jvm 1    | 2018/06/25 18:01:24 | 2018-06-25 18:01:24,379
[DefaultQuartzScheduler_Worker-1] DEBUG
com.redhat.rhn.taskomatic.task.ChannelRepodata - Put worker

And the last three lines about the workers are present 127 times (what does
it mean in terms of number of workers ? because here it doesn't look like
we have only the 2 default workers). It looks likes there's too much
channels in the queue for taskomatic to be able to handle them properly, no
matter how much memory we allocate to the service. The workers are put but
they don't really work...

And as always, the general behavior (task running forever) and the taskotop
output are the same.

Has anyone got an idea to explain this behavior ?

Regards,
Florence

2018-06-22 19:12 GMT+02:00 Gerald Vogt <vogt at spamcop.net>:

> I have the same problem after upgrading from 2.6 to 2.8 on CentOS 6.9. I
> have even increased the memory as suggested by that link but it makes no
> differences. None of the scheduled tasks are running. I can run a bunch
> manually. But the scheduler doesn't seem to work. Last execution times on
> the task engine status pages are still at timestamps from before the
> upgrade. -Gerald
>
>
>
>
> On 22.06.18 14:15, Avi Miller wrote:
>
>> Hi,
>>
>> On 22 Jun 2018, at 5:51 pm, Florence Savary <florence.savary.fs at gmail.com>
>>> wrote:
>>>
>>> When using taskotop, we can see a line for the channel-repodata task, we
>>> see it is running, but there is never any channel displayed in the Channel
>>> column. We can also see the task marked as running in the Admin tab of the
>>> WebUI, but if we let it, it never stops. The task runs indefinitely,
>>> whithout ever doing anything.
>>>
>>
>> If you've never modified the default memory settings, Taskomatic is
>> probably running out of memory and task is crashing. This is a known issue,
>> particularly when you sync large repos.
>>
>> I would suggest increasing the memory assigned to Taskomatic to see if
>> that resolves the issue. You will need to restart it after making these
>> changes: https://docs.oracle.com/cd/E92593_01/E90695/html/swk24-issue
>> s-memory.html
>>
>> Cheers,
>> Avi
>>
>> --
>> Oracle <http://www.oracle.com>
>> Avi Miller | Product Management Director | +61 (3) 8616 3496
>> Oracle Linux and Virtualization
>> 417 St Kilda Road, Melbourne, Victoria 3004 Australia
>>
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20180626/c98b16f2/attachment.htm>