Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When successfully logged in as AD-LDAP user into satellite web ui,
Passenger request queue gets maxed up, no matter how big
PassengerMaxRequestQueueSize
PassengerMaxPoolSize
are set up.
It will return message:
"This website is under heavy load"
If used wrong credentials, users gets rejected and all is OK.
On 6.1.4 everything working
Version-Release number of selected component (if applicable):
How reproducible:
100%
Steps to Reproduce:
1. configure satellite server to use LDAP settings
2. create user within Active Directory - LDAP
3. log in
Actual results:
Message
This website is under heavy load
passenger-status
ersion : 4.0.18
Date : Wed Jan 06 09:06:55 +0000 2016
Instance: 2553
----------- General information -----------
Max pool size : 6
Processes : 6
Requests in top-level queue : 0
----------- Application groups -----------
/usr/share/foreman#default:
App root: /usr/share/foreman
Requests in queue: 100
* PID: 4153 Sessions: 1 Processed: 342 Uptime: 40h 14m 12s
CPU: 27% Memory : 281M Last used: 40h 11m
* PID: 12493 Sessions: 1 Processed: 6012 Uptime: 39h 49m 49s
CPU: 25% Memory : 165M Last used: 36h 23m
* PID: 12504 Sessions: 1 Processed: 11161 Uptime: 39h 49m 48s
CPU: 24% Memory : 165M Last used: 35h 6m
* PID: 12517 Sessions: 1 Processed: 803 Uptime: 39h 49m 47s
CPU: 27% Memory : 162M Last used: 39h 24m
/etc/puppet/rack#default:
App root: /etc/puppet/rack
Requests in queue: 0
* PID: 2698 Sessions: 0 Processed: 43738 Uptime: 40h 15m 59s
CPU: 3% Memory : 148M Last used: 4s ago
* PID: 2702 Sessions: 0 Processed: 44641 Uptime: 40h 15m 59s
CPU: 3% Memory : 147M Last used: 9s ago
Expected results:
Requests in queue: lesser than 100 no error message.
Logged in
Additional info:
CSM Comment: Update for customer? Release date required and focus is specifically on the CONTAINERS. **Please update customer, they are beginning to get very frustrated and considering dropping Satellite for an alternative product from another vendor.**
Hi there,
Would it please be possible to give customer an update as there's been nothing customer facing for nearly a month now.
From our last call on 17.2.16 with customer the update from them was: Can container management updates be made more usable (from customer)? Question needs answering. Case needs immediate focus and update facing update relating to question please.
Many thanks,
Pippa
Customer Success Manager
Red Hat Customer Experience & Engagement, EMEA
Red Hat UK Ltd, 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hampshire, GU14 7JP.
Email: psteele |Mobile: +44 7917186036| Desk: +44 1252 362734
Comment 8Daniel Lobato Garcia
2016-03-31 06:37:49 UTC
Comment 9Daniel Lobato Garcia
2016-04-04 06:31:48 UTC
Stefan, I don't see how container management has anything to do with this bug?
I'm closing as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1277085 - which exhibited similar logs, and is fixed via the latest ldap_fluff. Please reopen if you still see this issue with ldap_fluff 0.4.1
*** This bug has been marked as a duplicate of bug 1277085 ***
Comment 11Red Hat Bugzilla
2023-09-14 03:15:59 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Description of problem: When successfully logged in as AD-LDAP user into satellite web ui, Passenger request queue gets maxed up, no matter how big PassengerMaxRequestQueueSize PassengerMaxPoolSize are set up. It will return message: "This website is under heavy load" If used wrong credentials, users gets rejected and all is OK. On 6.1.4 everything working Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. configure satellite server to use LDAP settings 2. create user within Active Directory - LDAP 3. log in Actual results: Message This website is under heavy load passenger-status ersion : 4.0.18 Date : Wed Jan 06 09:06:55 +0000 2016 Instance: 2553 ----------- General information ----------- Max pool size : 6 Processes : 6 Requests in top-level queue : 0 ----------- Application groups ----------- /usr/share/foreman#default: App root: /usr/share/foreman Requests in queue: 100 * PID: 4153 Sessions: 1 Processed: 342 Uptime: 40h 14m 12s CPU: 27% Memory : 281M Last used: 40h 11m * PID: 12493 Sessions: 1 Processed: 6012 Uptime: 39h 49m 49s CPU: 25% Memory : 165M Last used: 36h 23m * PID: 12504 Sessions: 1 Processed: 11161 Uptime: 39h 49m 48s CPU: 24% Memory : 165M Last used: 35h 6m * PID: 12517 Sessions: 1 Processed: 803 Uptime: 39h 49m 47s CPU: 27% Memory : 162M Last used: 39h 24m /etc/puppet/rack#default: App root: /etc/puppet/rack Requests in queue: 0 * PID: 2698 Sessions: 0 Processed: 43738 Uptime: 40h 15m 59s CPU: 3% Memory : 148M Last used: 4s ago * PID: 2702 Sessions: 0 Processed: 44641 Uptime: 40h 15m 59s CPU: 3% Memory : 147M Last used: 9s ago Expected results: Requests in queue: lesser than 100 no error message. Logged in Additional info: