> А бесконечность не кончилась с приходом systemd у тебя? У меня вот
> кончилась. Причём, не всё было так страшно в начале, как стало
> потом.Наоборот же, завезли:
https://lists.freedesktop.org/archives/systemd-devel/2016-Fe...
> [systemd-devel] [ANNOUNCE] systemd v229
> * Most configurable timeouts in systemd now expect an argument of
> "infinity" to turn them off, instead of "0" as before. The semantics
> from now on is that a timeout of "0" means "now", and "infinity"
> means "never".
И даже не забыли заботливо разложить грабли:
> To maintain backwards compatibility, "0" continues to
> turn off previously existing timeout settings.
https://unix.stackexchange.com/questions/352749/changing-sys...
> Changing systemd.service TimeoutSec value to “infinity” has no effect
Старательно их [грабли со значением 0 в таймаутах старых версий] обкостылять:
https://github.com/systemd-mailing-devs/systemd-mailing-list...
+ /* Traditionally, these options accepted 0 to disable the timeouts. However, a timeout of 0 suggests it happens
+ * immediately, hence fix this to become USEC_INFINITY instead. This is in-line with how we internally handle
+ * all other timeouts. */
+
+ if (s->timeout_start_usec <= 0)
+ s->timeout_start_usec = USEC_INFINITY;
и хорошенько разогнавшись,на них же и наступить:
https://github.com/systemd-mailing-devs/systemd-mailing-list...
> Since commit 36c16a7 ("core: rework unit timeout handling, and add
> new setting RuntimeMaxSec=") TimeoutSec=0 in mount units has
> cause the mount to timeout immediately instead of never as documented.
Цирк. С понями.
