systemd: fix setting of timeouts for device units

[msekletar]

JobRunningTimeoutSec now affects how long can start jobs for device
units stay in the "running" state. Disabling default job timeout via
JobTimeoutSec=0 doesn't disable running state timeout. We need to set
running state timeout as well.

Note that doing this the other way around has effect on generic timeout,
i.e. disabling running state timeout disables generic timeout. But doing
it this way we would create implicit dependency on fairly new
systemd-234. However, by setting both options we don't create dependency
on specific systemd version.

[centos-ci]

Can one of the admins verify this patch?

[kparal]

This is needed for resolving a Fedora 27 blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1495635
Please review soon, thanks.

[lnykryn]

Looks good to me. Lennart suggested to use "infinity" here, but I would stick with 0 since it is bit more compatible with older versions of systemd.

[jimklimov]

Hello, FYI : I've had an issue with my Debian based system (can't really tell the version, started as 8 but apt-updated a lot since then). I installed dracut packages, and lost my boot-ability, and followed the bread crumbs from the error message to this issue. And it was nail-on: whatever version of systemd I have, apparently takes the 0 timeout at face value and the sysroot.mount unit dies instantly, failing the boot (and curiously, mounting me the /sysroot into the recovery environment).

After a bit of digging in the miniroot's copy of dracut scripts (rootfs-generator specifically) I found it uses the rd.timeout value by default and falls back to 0 otherwise. So I edited grub.conf to set rd.timeout=infinity et voila, my system booted again.

So not sure if the dracut team would take this "feature" into account for future versions, but at least the data point may help future poor souls who get into same peril.