Alan Jenkins 5701836121 mount: clarify that umount retries do not (anymore) allow multiple timeouts
It _looks_ as if, back when we used to retry unsuccessful calls to umount,
this would have inflated the effective timeout.  Multiplying it by
RETRY_UMOUNT_MAX.  Which is set to 32.

I'm surprised if it's true: I would have expected it to be noticed during
the work on NFS timeouts.  But I can't see what would have stopped it.

Clarify that I do not expect this to happen anymore.  I think each
individual umount call is allowed up to the full timeout, but if umount
ever exited with a signal status, we would stop retrying.

To be extra clear, make sure that we do not retry in the event that umount
perversely returned EXIT_SUCCESS after receiving SIGTERM.
2018-01-23 11:09:18 +00:00
2017-12-30 12:23:24 +01:00
2017-12-07 17:12:13 +09:00
2018-01-12 18:02:57 +01:00
2017-11-29 14:33:56 +01:00
2017-12-25 19:48:49 +01:00
2016-10-06 11:53:58 -04:00
2018-01-11 15:10:29 +01:00

systemd - System and Service Manager

Count of open issues over time Count of open pull requests over time Build Status
Coverity Scan Status
CII Best Practices

Details

General information about systemd can be found in the systemd Wiki.

Information about build requirements are provided in the README file.

Consult our NEWS file for information about what's new in the most recent systemd versions.

Please see the HACKING file for information how to hack on systemd and test your modifications.

Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.

When preparing patches for systemd, please follow our Coding Style Guidelines.

If you are looking for support, please contact our mailing list or join our IRC channel.

S
Description
systemd patched fork
Readme
409 MiB
Languages
C 88.5%
Shell 5.7%
Python 4.6%
Meson 1.1%