[systemd-devel] systemd: support for new timeouts in .service

Michal Schmidt mschmidt at redhat.com
Mon Jul 23 05:57:31 PDT 2012


On 07/20/2012 12:08 PM, Michal Sekletar wrote:
> we found this bug https://bugzilla.redhat.com/show_bug.cgi?id=807885 and
> we already invested some effort to introducing new timeout types. We
> have a patch prepared introducing new service timeout types, namely
> TimoutStartSec and TimeoutStopSec.

I agree with the decision to introduce the two new timeout options, 
while still supporting TimeoutSec for compatibility.

 > Semantic would be as follows. Old
> timeout TimeoutSec defines common timeout for both, start and stop of
> service. If new timeout is used it will override current setting, which
> is either specified by TimeoutSec or default.  However another variant
> which was proposed by Michal Schmidt, changes described behavior in a
> way that timeout which is specified last in unit file is applied and
> always overrides the previous settings.

I don't think this description explains the difference well enough, so 
let me help by providing some examples:

Example #1:

/usr/lib/systemd/system/foo.service:
  ...
  [Service]
  TimeoutSec=100
  ...

/etc/systemd/system/foo.service:
  .include /usr/lib/systemd/system/foo.service
  [Service]
  TimeoutStopSec=200

In this example I believe we both agree that the result would be:
  start timeout = 100
  stop timeout  = 200


Example #2:

/usr/lib/systemd/system/foo.service:
  ...
  [Service]
  TimeoutStartSec=50
  TimeoutStopSec=100
  ...

/etc/systemd/system/foo.service:
  .include /usr/lib/systemd/system/foo.service
  [Service]
  TimeoutSec=200

In this example we disagree. In your proposal the TimeoutSec would be 
entirely ignored, because new timeout options were used. I.e. the result 
would be:
  start timeout = 50
  stop timeout  = 100
With my proposal the result would be:
  start timeout = 200
  stop timeout  = 200
because the TimeoutSec would have the same effect as setting both 
TimeoutStartSec= and TimeoutStopSec=.

The advantage of my proposal is that the administrator's override (which 
may have been in place before the introduction of the new timeout 
options) is still effective.

> We are interested in opinion of systemd community in regard to this
> matter. Thank you.



More information about the systemd-devel mailing list