[Pulp-list] Issues with node repo sync

[Christina Plummer]

Saw the Request Timeout errors again yesterday when trying to do a node
sync.  I was actually doing a tcpdump on the parent, and did not see any
traffic on port 5672 until I had restarted both qpidd on the parent, and
goferd on the child.

Barnaby - does this sound like the known issue you mentioned?


On Thu, Jun 5, 2014 at 9:29 AM, Christina Plummer <cplummer at gmail.com>
wrote:

> Sorry - I am running 2.3.1-1.
>
> Jason - thanks for the tip, I will check for that the next time I get the
> error.
>
>
> On Thu, Jun 5, 2014 at 9:17 AM, Ashby, Jason (IMS) <AshbyJ at imsweb.com>
> wrote:
>
>>  I get the same with pulp 2.3, and I’ve found that even though I get the
>> RequestTimeout on the command line, the sync is still running on the
>> server.  You should be able to check the qpid agent logs on the node(s) in
>> /var/log/gofer/agent.log to confirm that your repos were synced, e.g.
>>
>>
>>
>>
>>
>> 2014-06-04 22:40:01,591 [INFO][worker-0] update() @ model.py:474 -
>> Importer: some-repo/nodes_http_importer, updated
>>
>> 2014-06-04 23:39:01,591 [INFO][worker-0] update() @ model.py:474 -
>> Importer: some-other-repo/nodes_http_importer, updated
>>
>> etc...
>>
>>
>>
>> *From:* pulp-list-bounces at redhat.com [mailto:pulp-list-bounces at redhat.com]
>> *On Behalf Of *Christina Plummer
>> *Sent:* Wednesday, June 04, 2014 6:52 PM
>> *To:* pulp-list at redhat.com
>>
>> *Subject:* [Pulp-list] Issues with node repo sync
>>
>>
>>
>> Whenever I go to do a "pulp-admin node sync run", if it has been more
>> than a day or so since my last sync, I get timeout errors like this:
>>
>>
>> Task Failed
>>
>> [u"RequestTimeout: ('f7f2024f-60b8-4460-9ba8-46a716f39ab2', 0)\n"]
>>
>>  The only way I have found to fix it is:
>>
>>  1. Restart qpidd service on the parent
>>
>>  2. Restart pulp-agent service on the child
>>
>> Both steps seem to be required.  My child and parent are located in
>> separate data centers, currently connected by a VPN tunnel, so connections
>> do drop/timeout every now and then.  But shouldn't it be more resilient
>> than this?
>>
>> Thanks,
>> Christina
>>
>> ------------------------------
>>
>> Information in this e-mail may be confidential. It is intended only for
>> the addressee(s) identified above. If you are not the addressee(s), or an
>> employee or agent of the addressee(s), please note that any dissemination,
>> distribution, or copying of this communication is strictly prohibited. If
>> you have received this e-mail in error, please notify the sender of the
>> error.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20140606/8e37a63e/attachment.htm>