Bug 1446015 - systemd fails to start a service if TimeoutSec=infinity is used
Summary: systemd fails to start a service if TimeoutSec=infinity is used
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
: 1638138 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-04-27 02:46 UTC by Sergei Turchanov
Modified: 2019-06-19 18:12 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-06-19 18:12:15 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4236301 0 Troubleshoot None Why does a systemd service immediately timeout when "infinity" is set for TimeoutSec, TimeoutStartSec, or TimeoutStopSec... 2019-06-19 18:12:15 UTC

Description Sergei Turchanov 2017-04-27 02:46:16 UTC
Description of problem:

systemd fails to start a service if TimeoutSec=infinity is used. Tested with 'oneshot' and 'forking' types. If I use something like "TimeoutSec=1y" everything goes as expected (i.e. service starts).

Version-Release number of selected component (if applicable):
RHEL 7.3

How to reproduce:

For oneshot service type:

# cat /usr/lib/systemd/system/test.service
Description=Test Service

ExecStart=/bin/sleep 3


Service start fails immediately (i.e. command returns immediately)

# systemctl start test.service
Job for test.service failed because a timeout was exceeded. See "systemctl status test.service" and "journalctl -xe" for details.

# systemctl status test.service
Apr 27 12:17:47 test.local systemd[1]: Starting Test Service...
Apr 27 12:17:47 test.local systemd[1]: test.service start operation timed out. Terminating.
Apr 27 12:17:47 test.local systemd[1]: Failed to start Test Service.
Apr 27 12:17:47 test.local systemd[1]: Unit test.service entered failed state.
Apr 27 12:17:47 test.local systemd[1]: test.service failed.

The same bug is with 'forking' type:

# cat /usr/lib/systemd/system/test.service
Description=Test Service




# cat /usr/libexec/test-service.sh
#! /bin/bash

sleep 1

sleep 10000&

Comment 2 Sergei Turchanov 2017-06-05 02:22:07 UTC
So, does anyone care?!

Comment 3 Jan Synacek 2017-06-05 08:14:04 UTC
Yes! This bug just isn't priority for us.

Comment 4 Ade Rixon 2017-12-12 14:08:30 UTC
FYI, upstream package postgresql93-server-9.3.20-3PGDG.rhel7.x86_64 breaks because of this issue:

* Thu Dec 07 2017 John K. Harvey <john.harvey@crunchydata.com> - 9.3.20-3PGDG
- Fixes for CVE-2017-12172 (EL-6 only)
- Update TimeOutSec parameter to match systemd docs (EL-7 only)

# systemctl start postgresql-9.3
Job for postgresql-9.3.service failed because a timeout was exceeded. See "systemctl status postgresql-9.3.service" and "journalctl -xe" for details.

(See http://www.postgresql-archive.org/BUG-14967-Postgresql-won-t-start-after-upgrade-from-postgresql93-9-3-20-1PGDG-rhel7-x86-64-td5996531.html )

However, I understand that 'infinity' as a timeout value is only recognised from systemd 229, whereas EL7 contains 219, so it looks like the PGSQL project may have jumped the gun here.

Comment 5 David Tardon 2019-01-31 09:57:05 UTC
The support for infinity was added in https://github.com/systemd/systemd/commit/36c16a7cdd6c33d7980efc2cd6a2211941f302b4 , which was quite a large change. Also, there was at least one regression-fixing follow-up commit: https://github.com/systemd/systemd/commit/89beff89edba592366b2960bd830d3f6e602c2c7 . Therefore I don't think it's a good candidate for backporting. But perhaps we could adapt the parser to accept "infinity" and interpret it the same way as 0: to disable the timeout.

Comment 6 David Tardon 2019-01-31 09:57:28 UTC
*** Bug 1638138 has been marked as a duplicate of this bug. ***

Comment 7 Kyle Walker 2019-06-19 18:12:15 UTC
I am closing this bug at this time in order to focus our efforts on higher priority issues.

The TimeoutSec, TimeoutStartSec, and TimeoutStopSec mechanisms within the revision of systemd for RHEL 7 (based on 219 with a steadily growing number of backports) are documented as the following in "man systemd.service":

           Configures the time to wait for start-up. If a daemon service does not signal start-up
           completion within the configured time, the service will be considered failed and will be
           shut down again. Takes a unit-less value in seconds, or a time span value such as "5min
           20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the
           manager configuration file, except when Type=oneshot is used, in which case the timeout is
           disabled by default (see systemd-system.conf(5)).

           This option serves two purposes. First, it configures the time to wait for each ExecStop=
           command. If any of them times out, subsequent ExecStop= commands are skipped and the
           service will be terminated by SIGTERM. If no ExecStop= commands are specified, the service
           gets the SIGTERM immediately. Second, it configures the time to wait for the service itself
           to stop. If it doesn't terminate in the specified time, it will be forcibly terminated by
           SIGKILL (see KillMode= in systemd.kill(5)). Takes a unit-less value in seconds, or a time
           span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to
           DefaultTimeoutStopSec= from the manager configuration file (see systemd-system.conf(5)).

           A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified

As noted above, the method to disable the timeout logic is to use the "0" value. The "infinity" value was not available until the upstream 229 release. 

The use of "infinity" is now available within the RHEL 8 release, as it is based upon upstream systemd 239. As indicated by David above, the backport for allowing "infinity" use instead of "0" is currently deemed to risky to existing installations to proceed forwards with within the RHEL 7 release.

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