Bug 1441212 - Increase TimeoutStartSec for httpd.service
Summary: Increase TimeoutStartSec for httpd.service
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Installer
Version: 6.2.7
Hardware: All
OS: Linux
medium
medium vote
Target Milestone: Unspecified
Assignee: Ivan Necas
QA Contact: jcallaha
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks: 1479962
TreeView+ depends on / blocked
 
Reported: 2017-04-11 12:40 UTC by Pavel Moravec
Modified: 2021-08-30 12:11 UTC (History)
13 users (show)

Fixed In Version: foreman-installer-1.15.6.6-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 16:54:17 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 21023 0 High Closed Increase TimeoutStartSec for httpd.service 2020-10-17 19:29:00 UTC
Foreman Issue Tracker 21295 0 Normal Closed Slow start of rails environment when starting passenger or foreman-tasks 2020-10-17 19:29:00 UTC
Red Hat Knowledge Base (Solution) 2998741 0 None None None 2017-04-11 13:40:12 UTC

Description Pavel Moravec 2017-04-11 12:40:55 UTC
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:

Comment 2 Stephen Benjamin 2017-04-11 13:16:32 UTC
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?

Comment 3 Pavel Moravec 2017-04-11 13:40:13 UTC
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.

Comment 4 Stephen Benjamin 2017-04-11 14:06:02 UTC
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 6 Satellite Program 2017-10-19 14:24:28 UTC
Upstream bug assigned to inecas@redhat.com

Comment 7 Satellite Program 2017-10-19 14:24:32 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21295 has been resolved.

Comment 8 Satellite Program 2017-10-19 16:23:38 UTC
Upstream bug assigned to chrobert@redhat.com

Comment 9 Satellite Program 2017-10-19 16:23:42 UTC
Upstream bug assigned to chrobert@redhat.com

Comment 10 Satellite Program 2017-10-26 22:27:47 UTC
Upstream bug assigned to inecas@redhat.com

Comment 11 Satellite Program 2017-10-26 22:27:52 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21295 has been resolved.

Comment 12 Zach Huntington-Meath 2017-12-20 21:41:49 UTC
Ivan, would you mind cherry-picking this downstream?

Comment 13 Ivan Necas 2017-12-21 06:55:43 UTC
My part is already in downstream, deferring to @toledo about the puppet part

Comment 14 Chris Roberts 2018-01-03 22:58:00 UTC
This is complete with this:

https://gitlab.sat.lab.tlv.redhat.com/satellite6/puppet-foreman/merge_requests/7

Comment 15 jcallaha 2018-01-30 16:56:07 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 16 Satellite 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


Note You need to log in before you can comment on or make changes to this bug.