I guess this depends on the status of the Apache httpd workers. Like are they stuck in IO to the /mnt/koji scratch location, or something else?

Unfortunately it's not secure to publicly display Koji's in-flight HTTP requests with mod_status, since the URLs contain the authenticated session information, but that's where I'd go for the next level of investigation if this happens frequently.

Maybe we need a separate utility in kojiweb to sanitize the hub's mod_status' output for the public and display "what's the hub doing now".

- Ken

On Thu, Mar 7, 2019, 12:08 PM Richard Shaw <hobbes1069@gmail.com> wrote:
On Wed, Mar 6, 2019 at 6:39 PM Kevin Fenzi <kevin@scrye.com> wrote:
On 3/6/19 4:14 PM, Richard Shaw wrote:
>
> New since the last couple of weeks but I've been more active working on
> FTBFS issues so can't say exactly when it started. It's never been super
> speedy but also never been this painful.

Odd. I can't think of anything on the server end that has changed
recently that might cause this. It's just as fast as always for me.

Has curl been updated on your machine(s) around the time it started?

Does koji --debug build scratch tag src.rpm

Hah... just tried it and the srpm uploaded at >1MB/sec...

Thanks,
RIchard 
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org