systemd / systemd/systemd

Deprecate TimeoutSec= in favour of TimeoutStartSec=/TimeoutStopSec=

Open
#11,155 6 comments 1 reaction 1 assignee View on GitHub

@cdown is already working on this.

Since Dec 17, 2018.

pid1
Dominant language
C
Stars
16.7k
Forks
4.7k
Avg merge
1d 6h
Merged PRs (30d)
140

Description

In 188, we split out TimeoutSec into TimeoutStartSec and TimeoutStopSec. Unfortunately many people still see TimeoutSec and immediately jump to the intuitively logical conclusion for one who's thinking about "timeout" strictly in terms of the service itself: that TimeoutSec relates to a timeout for service or activation startup. If I had a dollar for every time people thought that the behaviour of TimeoutSec is equivalent to TimeoutStartSec, I'd be a rich man.

This is actually somewhat of a problem, because for some services it may make sense to set TimeoutStartSec=infinity, but it almost certainly doesn't make sense in those same services to set TimeoutStopSec=infinity. Nonetheless, a lot of people in this situation end up setting TimeoutSec=infinity and ending up with services stuck forever in deactivating. This has caused a number of issues with people complaining that their services aren't managed in the way they expect inside FB, at least.

I don't think there's any easy solution to stop people doing the wrong thing, but my proposal is to:

  1. In a future version, emit a log warning about using TimeoutSec, advising it will become equivalent to TimeoutStartSec in the next release
  2. In the next version after that, alias TimeoutSec to TimeoutStartSec, and make TimeoutBothSec (perhaps?) which does what TimeoutSec used to

Thoughts? I'm usually in favour of keeping backwards compatibility, but TimeoutSec seems a directive that's really rife with people shooting themselves in the foot due to having a non-obvious name.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.