mirror of
https://github.com/morgan9e/systemd
synced 2026-04-15 08:56:15 +09:00
006aabbd05
"Due to the io event priority logic we can be sure the new mountinfo is loaded before we process the SIGCHLD for the mount command." I think this is a reasonable expectation. But if it works, then the other comment must be false: "Note that mount(8) returning and the kernel sending us a mount table change event might happen out-of-order." Therefore we can clean up the code for the latter. If this is working as advertised, then we can make sure that mount units fail if the mount we thought we were creating did not actually appear, due to races or trickery (or because /sbin/mount did something unexpected despite returning EXIT_SUCCESS). Include a specific warning message for this failure. If we give up when the mount point is still mounted after 32 successful calls to /sbin/umount, that seems a fairly similar case. So make that message a LOG_WARN as well (not LOG_DEBUG). Also, this was recently changed to only retry while umount is returning EXIT_SUCCESS; in that case in particular there would be no other messages in the log to suggest what had happened.
systemd - System and Service Manager
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.