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!
Upstream bug assigned to inecas
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21295 has been resolved.
Upstream bug assigned to chrobert
Ivan, would you mind cherry-picking this downstream?
My part is already in downstream, deferring to @toledo about the puppet part
This is complete with this: https://gitlab.sat.lab.tlv.redhat.com/satellite6/puppet-foreman/merge_requests/7
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
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