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:
httpd config has:
PassengerStartTimeout 600
allowing Passenger to be kicking off for that long time. However, httpd service uses systemd default timeout 90s (I *think* it's 90).
So there can be cases (and already is one case) when Passenger started within its timeout limit but after systemd timeout, causing systemd killed the still-starting httpd service.
Please increase httpd.service startup timeout to something more reasonable (not sure if 600s isnt too much, if it won't rather mask potential deadlocks during startup - leaving the decision of particular value to devels).
Version-Release number of selected component (if applicable):
Sat 6.2.*
How reproducible:
100%
Steps to Reproduce:
1. Install Sat6.
2. grep TimeoutStartSec /etc/systemd/system/httpd.service.d/*
Actual results:
no such timeout
Expected results:
Timeout is present with some reasonable value.
Additional info:
FWIW, we shouldn't change the value in the packaged unit file, it should be in a systemd drop-in, like /etc/systemd/system/httpd.service.d/10-larger_timeout.conf.
Do you know why the passenger took so long to start? 600 seconds seems like overkill, do you think maybe we should try to match the httpd timeout instead?
No idea why Passenger took so much time (see satellite6 mailing list for my question on this and KCS 2998741 for particular timings). Is there a way to debug Passenger to identify why it is starting so slowly?
If we set Passenger timeout to 90 to match systemd timeout, the customer behind this case wont be able to start httpd either. I guess the 90s should be sufficient, but I ma not developer. Simply a component of httpd shall not have bigger startup timeout than httpd service itself.
Ok thanks. Looks like we intentionally raised the PassengerTimeout to 600 in https://bugzilla.redhat.com/show_bug.cgi?id=1103224, which maybe works fine on el6 but not systemd distros.
We'll probably have to do what you originally suggested, thanks!
Comment 6Satellite Program
2017-10-19 14:24:28 UTC
Upstream bug assigned to inecas
Comment 7Satellite Program
2017-10-19 14:24:32 UTC
Verified in Satellite 6.3 Snap 33. The new timeout has been updated to 90 seconds.
-bash-4.2# grep PassengerStartTimeout /etc/httpd/conf.d/05-foreman.conf
PassengerStartTimeout 90
-bash-4.2# grep passenger_start_timeout /usr/share/foreman-installer/modules/foreman/manifests/params.pp
$passenger_start_timeout = 90
Comment 16Satellite Program
2018-02-21 16:54:17 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.
>
> For information on the advisory, and where to find the updated files, follow the link below.
>
> If the solution does not work for you, open a new bug report.
>
> https://access.redhat.com/errata/RHSA-2018:0336