Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Re-export if zfs-mount.service failed #15607

Closed
SilverBut opened this issue Nov 29, 2023 · 7 comments · Fixed by #15660
Closed

Re-export if zfs-mount.service failed #15607

SilverBut opened this issue Nov 29, 2023 · 7 comments · Fixed by #15660
Labels
Type: Feature Feature request or new feature

Comments

@SilverBut
Copy link

Describe the feature would like to see added to OpenZFS

For systemd users, zfs-mount.service might fail temporarily, and could be restored manually by systemctl restart zfs-mount. However, the file systems exported by zfs-export.service is not re-exported, causing newly mounted filesystems not exported, even if fields like sharenfs is set.

How will this feature improve OpenZFS?

Improve resiliency of exported filesystem if mount failed.

Additional context

Consider modify zfs-share.service:

[Unit]
# ...
PartOf=zfs-mount.service
#...
@SilverBut SilverBut added the Type: Feature Feature request or new feature label Nov 29, 2023
@stfl
Copy link
Contributor

stfl commented Dec 7, 2023

There is no zfs-export.service. I am assuming, you are referring to zfs-share.service, right?
How do you notice that zfs-mount fails? Can you share a journal from the time the service fails?
Can you reproduce it?

Do you see the issue of disappearing nfs exports after a reboot?

Does adding PartOf=zfs-mount.service solve the problem?

@stfl
Copy link
Contributor

stfl commented Dec 7, 2023 •
edited

I can verify that nfs shares disapper after restarting the zfs-mount.service
Adding the PartOf as an override makes restarting the service work.

/etc/systemd/system/zfs-share.service.d/override.conf

[Unit]
PartOf=zfs-mount.service

@behlendorf
Copy link
Contributor

@SilverBut @stfl could you open a PR with this proposed fix for review.

stfl added a commit to stfl/zfs that referenced this issue Dec 7, 2023
@stfl
define zfs-share to be PartOf zfs-mount in systemd unit
5c6d6c7 
Fixes: openzfs#15607

This forces zfs-share to restart with zfs-mount
stfl added a commit to stfl/zfs that referenced this issue Dec 7, 2023
@stfl
systemd: define zfs-share to be PartOf zfs-mount
2827fe5 
Fixes: openzfs#15607

This forces zfs-share to restart with zfs-mount
@SilverBut
Copy link
Author

SilverBut commented Dec 7, 2023 •
edited

Oh yes @stfl, it was zfs-share.service, sorry for (big) typo.

And @behlendorf I saw #15652, and seems good. But actually I have a vague memory of the filesystems was actually correctly exported after mounted, really not sure. Also I met this unexported problem after a upgrade.

I have to admit I did not read all release notes of recent OpenZFS releases. So I'm not sure if it has been broken since very early time, or it was something broke it in recent versions. PartOf= is more about a workaround (and, only for systemd), which I'm also happy to see, and so far I have not met any side effects. But I would thank everyone passing by if you can help to dig through it.

@SilverBut
Copy link
Author

Add: If anyone wants to reproduce it, try to make zfs mount fail temporarily during boot (so the service would fail), and restore to mount it again after boot done.

@stfl
Copy link
Contributor

stfl commented Dec 11, 2023

I can confirm, that rebooting is not fixed with PartOf as mentioned in our bug tracker at Proxmox: https://bugzilla.proxmox.com/show_bug.cgi?id=5101

@stfl
Copy link
Contributor

stfl commented Dec 11, 2023

In fact, fixing the systemd service would not have solved the issue. When running zfs mount -a directly, the nfs shares disappear and systemd cannot do anything about it..

I have now identified the different behavior between 2.1 and 2.2.
When running zfs mount -a it does reset the nfs shares in 2.2, while it doesn't in 2.1
I am working on the fix for that, which will hopefully also fix this after a reboot.

@stfl stfl mentioned this issue Dec 11, 2023
Merged
13 tasks
behlendorf pushed a commit that referenced this issue Jan 12, 2024
@stfl
fix(mount): do not truncate shares not zfs mount
66670ba 
When running zfs share -a resetting the exports.d/zfs.exports makes
sense the get a clean state.
Truncating was also called with zfs mount which would not populate the
file again.
Add test to verify shares persist after mount -a.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Closes #15607 
Closes #15660
behlendorf pushed a commit to behlendorf/zfs that referenced this issue Jan 29, 2024
@stfl @behlendorf
fix(mount): do not truncate shares not zfs mount
e156fa9 
When running zfs share -a resetting the exports.d/zfs.exports makes
sense the get a clean state.
Truncating was also called with zfs mount which would not populate the
file again.
Add test to verify shares persist after mount -a.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Closes openzfs#15607 
Closes openzfs#15660
behlendorf pushed a commit that referenced this issue Jan 29, 2024
@stfl @behlendorf
fix(mount): do not truncate shares not zfs mount
4db88c3 
When running zfs share -a resetting the exports.d/zfs.exports makes
sense the get a clean state.
Truncating was also called with zfs mount which would not populate the
file again.
Add test to verify shares persist after mount -a.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Closes #15607 
Closes #15660
lundman pushed a commit to openzfsonwindows/openzfs that referenced this issue Mar 13, 2024
@stfl @lundman
fix(mount): do not truncate shares not zfs mount
321c674 
When running zfs share -a resetting the exports.d/zfs.exports makes
sense the get a clean state.
Truncating was also called with zfs mount which would not populate the
file again.
Add test to verify shares persist after mount -a.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Closes openzfs#15607 
Closes openzfs#15660
lundman pushed a commit to openzfsonwindows/openzfs that referenced this issue Mar 13, 2024
@stfl @lundman
fix(mount): do not truncate shares not zfs mount
f566f3b 
When running zfs share -a resetting the exports.d/zfs.exports makes
sense the get a clean state.
Truncating was also called with zfs mount which would not populate the
file again.
Add test to verify shares persist after mount -a.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Closes openzfs#15607 
Closes openzfs#15660
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Feature Feature request or new feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(mount): do not truncate shares not zfs mount stfl/zfs
3 participants
@behlendorf @stfl @SilverBut