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.
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
samba: don't restart smbd in samba-autoshare #1919
Conversation
While it's mostly true that if you simply update However, that's not always the case, and sometimes a newly added share will refuse to be listed on the client - sometimes for several minutes - until In addition, when a drive is unmounted although the share will be removed from A "lingering" disconnected share could have catastrophic consequences - if a drive is unmounted without restarting Simply updating the config without restarting The only way to reliably add or remove a share is to restart So while we will see a storm of service stop/starts at startup (hopefully lessened to some extent by recent changes), I think it's a necessary evil to avoid listing non-existent shares (which could be dangerous, leading to potential data loss), or not immediately listing new shares (which can be very frustrating for the user who wants to access their new share etc.). |
Note: I've been testing with a Windows 7 client, which behaves exactly as described above. |
According to the manual: "The configuration file, and any files that it includes, are automatically reloaded every minute, if they change. You can force a reload by sending a SIGHUP to the server. Reloading the configuration file will not affect connections to any service that is already established. Either the user will have to disconnect from the service, or smbd killed and restarted." So to speed up the configuration refresh one could use SIGHUP, but yes any already established connection will probably have the same configuration as when the client connected. Doing a complete restart doesn't seem like a good reason to me either way, for the above reason and also that any ongoing file operations to a share will be interrupted. I don't see how you can avoid these "lingering" shares that you mention, as normally samba-autoshare is triggered by udev add/remove -> udevil-mount service. A user could manually unmount a drive and the share would still linger with or without this PR. |
Added a HUP. |
@@ -21,6 +21,8 @@ if [ -f /storage/.cache/services/samba.conf ]; then | |||
. /storage/.cache/services/samba.conf | |||
|
|||
if [ "$SAMBA_AUTOSHARE" == "true" ] ; then | |||
systemctl restart smbd.service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if possible, systemctl reload smbd.service
should be used and re-runing samba-config and smbd-config should be moved to additional ExecReload=
s in smbd.service
[Service]
Type=forking
...
ExecReload=/usr/lib/samba/smbd-config
ExecReload=/usr/bin/systemctl restart samba-config.service
ExecReload=/bin/kill -HUP $MAINPID
...
sorta
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion, that also gives the user a clean way of reloading after manual changes to the configuration. I'll test it and revise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work as intended. Udevil mounts drives before samba is started, and a service can't be reloaded until it's active:
Aug 25 14:06:03 NUC samba-autoshare[412]: smbd.service is not active, cannot reload.
Aug 25 14:06:03 NUC systemd[1]: smbd.service: Unit cannot be reloaded because it is inactive.
Aug 25 14:06:03 NUC samba-autoshare[410]: smbd.service is not active, cannot reload.
Aug 25 14:06:03 NUC systemd[1]: smbd.service: Unit cannot be reloaded because it is inactive.
Aug 25 14:06:03 NUC samba-autoshare[662]: smbd.service is not active, cannot reload.
It's trying to reload three times, once for System and Flash, then once for my external drive. As the reload doesn't trigger, the external drive isn't shared once Samba starts. If I trigger a reload after, it works as intended.
Not sure if it's possible/feasible to get udev/udevil to start after Samba. The PR as is works satisfactory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's trying to reload three times, once for System and Flash
Is your tree up to date? udevil-mount
should already ignore /system
and /flash
(and any other already mounted partition), see after #1800
The PR as is works satisfactory.
Yes, the addition of pkill -HUP smbd
has addressed my original concerns - thanks (and @stefansaraev).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, hadn't seen that change. I was testing this on 8.1 actually.
Just occasionally This means This is with one external drive (/dev/sda1, "Images") - installed at the time of booting - where the partition is mounted while
Reboot often enough and you should hit this condition. The following works:
which results in:
Alternatively, maybe there's some additional systemd magic to ensure that However as the pid file check seems to work, I'd go with that... |
The pid file check has been added. |
@escalade anything more to add on this? It's been in my builds for 2-3 weeks without any issue. |
Nothing to add, works fine here as well. |
OK thanks - removing WIP label. |
The samba-autoshare script that takes care of sharing mounted drives restarts smbd every time udevil mounts a disk. This can lead to a Samba restart frenzy on boot with several connected disks. This is unnecessary as Samba does not need to be restarted to pick up changes to shares in smb.conf.
This PR modifies samba-autoshare to simply regenerate the configuration (samba-config) and then extend the configuration according to LE settings (smbd-config).