[Spacewalk-list] Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds

Mon Oct 3 13:17:36 UTC 2016

Konstantin,

    I would try first to increase the time out in rhnplugin.conf
As far as I recall default is 120 seconds ( empty )

$ cat /etc/yum/pluginconf.d/rhnplugin.conf  | grep timeout
timeout = 720

Operation too slow. Less than 1000 bytes/sec      transferred the
      last 30 seconds (Konstantin Raskoshnyi)

On Fri, Sep 30, 2016 at 9:12 AM <spacewalk-list-request at redhat.com> wrote:

> Send Spacewalk-list mailing list submissions to
>         spacewalk-list at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.redhat.com/mailman/listinfo/spacewalk-list
> or, via email, send a message with subject or body 'help' to
>         spacewalk-list-request at redhat.com
>
> You can reach the person managing the list at
>         spacewalk-list-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Spacewalk-list digest..."
>
>
> Today's Topics:
>
>    1. Operation too slow. Less than 1000 bytes/sec      transferred the
>       last 30 seconds (Konstantin Raskoshnyi)
>    2. Schedule Reboot (Bug?) (Jeff Baldwin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 Sep 2016 11:17:13 -0700
> From: Konstantin Raskoshnyi <konrasko at gmail.com>
> To: spacewalk-list at redhat.com
> Subject: [Spacewalk-list] Operation too slow. Less than 1000 bytes/sec
>         transferred the last 30 seconds
> Message-ID:
>         <CAJU06NMBQCNbU5VbMiu0M=
> FaHt-rfP6hbRT602WjGcNhcBfE1Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Good morning,
> I keep getting this error with,
> http://192.168.1.2/repos/repodata/repomd.xml: (28, 'Operation too slow.
> Less than 1000 bytes/sec transferred the last 30 seconds')
>
> I have two spacewalk servers in different DCs and I keep some repo copies
> on one of them.
>
> I can do curl or wget http://192.168.1.2/repos/repodata/repomd.xml without
> any problems...
>
> Any thoughts?
>
> Thanks!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://www.redhat.com/archives/spacewalk-list/attachments/20160929/b1fb639d/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 30 Sep 2016 14:10:35 +0000
> From: Jeff Baldwin <JeffB at knowclassic.com>
> To: "spacewalk-list at redhat.com" <spacewalk-list at redhat.com>
> Subject: [Spacewalk-list] Schedule Reboot (Bug?)
> Message-ID: <E0495A44-2883-4BEE-A466-17FEBBF06CB6 at knowclassic.com>
> Content-Type: text/plain; charset="utf-8"
>
> All,
>
> I?ve ran into what appears to be an old bug.   The issue is that when
> systems are in ?Require Reboot? status, and I reboot them via Spacewalk,
> the status doesn?t update, even after OSAD has completed the reboot
> process.    I have to run rhn_check to force the status to update.   I
> found that this was discussed in an email back in 2014, but no resolution
> was mentioned in the thread:
> https://www.redhat.com/archives/spacewalk-list/2014-October/msg00067.html
>
> The scenario the user described below, still applies perfectly to my 2.5
> install (his was 2.2).
>
> Are we missing something?
>
> Steps I've taken already:
>
> 1. Set verbosity to level 5 on osad.conf for the client. Everything looks
> fine in the logs until after the reboot, when the server starts and the
> OSAD service starts, it's not checking in with Spacewalk even though OSA
> status says online.
>
> 2. Stop OSAD, remove /etc/sysconfig/rhn/osad-auth.conf, start OSAD. Same
> results. Reboot action is picked up immediately, and the system reboots
> successfully, but the action is never marked Completed.
>
> 3. Stopped jabberd on the Spacewalk proxy the client is connected to,
> cleared jabberd database, and restarted jabberd. I've done the same on the
> Spacewalk server, and tried them in different orders as well.
>
> 4. Manually running a shutdown -r now on the client. THIS WORKS. When the
> system comes back up, any queued actions are picked up and executed
> successfully. This is one of the main reasons it leads me to believe there
> is an issue with the Schedule reboot API in Spacewalk v2.2 (BTW, I've tried
> the API via Python script, as well as through the WebUI, same results where
> the action is never marked Completed).
>
> 5. Verified the client is running the latest versions of osad, rhnsd,
> rhn-client-tools, rhn-setup, and rhn-check from the 2.2 repo
>
> 6. Registered the client to a Spacewalk 2.0 environment. Everything works
> as it should there. No issues.
>
>
>  Jeff Baldwin
>
>
> [cid:logo_cg_s.png]
>
>  8335 Classic Drive
>  Charlotte, NC 28262
>  800.368.1056 toll free
>
>  704.597.9015 main
>  knowclassic.com<http://www.knowclassic.com>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://www.redhat.com/archives/spacewalk-list/attachments/20160930/d2f00445/attachment.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: logo_cg_s.png
> Type: image/png
> Size: 16563 bytes
> Desc: logo_cg_s.png
> URL: <
> https://www.redhat.com/archives/spacewalk-list/attachments/20160930/d2f00445/attachment.png
> >
>
> ------------------------------
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> End of Spacewalk-list Digest, Vol 100, Issue 22
> ***********************************************
>

-- 

Mintel Group Limited | 333 West Wacker Drive Suite 1100 | Chicago, Illinois USA 60606

Contact details for our other offices can be found at http://www.mintel.com/office-locations.

This email and any attachments may include content that is confidential, privileged 
 or otherwise protected under applicable law. Unauthorized disclosure, copying, distribution 
 or use of the contents is prohibited and may be unlawful. If you have received this email in error,
 including without appropriate authorization, then please reply to the sender about the error 
 and delete this email and any attachments.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161003/04346581/attachment.htm>