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.