Improve lazy_umount_nfs.service #20
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Import existing systemd service file into repository. We had the problem, that systemd tries to unmount all mounted file systems after the network already shut down and in the case of nfs mounts, this made it wait a long time for timeouts. This service is supposed to remove the unmountable nfs mounts from the mount tree (by layz umount) so that systemd doesn't not attempt to dismount them again. A clean unmount of the nfs mounts has already been attempted (by shutdown of automount), so we only have those nfs mounts left over, which are locked and can't be dismounted anyway.
Use shutdown.target as a synchronization point instead of individual
shutdown/reboot services.
shutdown.target has
RequiredBy=halt.service reboot.service poweroff.service
Before=halt.service final.target reboot.service poweroff.service
so this change shouldn't affect if and when lazy-umount-nfs.service is started.
lazy-umount-nfs.service sometimes stalled for several seconds during
shutdown. The assumed reason is, that is was started while automount was
still shuting down - possibly triggering new automounts.
Add a order dependency for automount.service. During shutdown,
automount.service is stopped (by its default dependency on
shutdown.target) and this service is started by its explicit dependency
on shutdown.target.
We could use "After=" or "Before=" [1], but "After=" seems a bit
more intuitive to me ("start lazy-umount-nfs.service AFTER
automount.service was stopped").
[1] `man systemd.unit` :
If one unit with an ordering dependency on another unit is shut down
while the latter is started up, the shut down is ordered before the start-up
regardless whether the ordering dependency is actually of type
After= or Before=.
When this service is started, automount already attempted to unmount the nfs mounts it is responsible for. However, we may have other nfs mounts (e.g. those done manually by a system administrator). If we just disconnect those, we would shutdown before attempting to write dirty data back and release delegations and locks on the server. Try a normal umount before we give up and just disconnect the mounts.
|
To update: |
|
On 02/15/18 11:21, Donald Buczek wrote:
To update:
sudo make install
sudo systemctl daemon-reload
sudo systemctl disable lazy-umount-nfs.service
sudo systemctl enable lazy-umount-nfs.service
For the record, in newer systemd version, `systemctl` features the
command `reenable`.
|
Sign in
to join this conversation on GitHub.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Start of lazy_umount_nfs.service and stop of automount.service were both triggered by shutdown.target but they had no order dependency. This might be the reason, why it sometimes didn't work as expected.