Univention Bugzilla – Bug 44953
/etc/logrotate.d/samba: SIGHUP deactivates change notification
Last modified: 2020-07-03 20:52:07 CEST
The standard Samba 4 logging has a side effect. Sending a kill signal at the logrotate deactivates caching in Samba 4. The result is that on all shares the folder and file view is not updated automatically and has to be triggered manually with F5. This is annoying in larger environments. Reported by a partner via feedback Ticket#2017070321000438.
Actually that's the result of my analysis for Ticket#2017070321000438.
Ticket#2017020621000156 that is.
Also: in the samba-shares listener (/usr/lib/univention-directory-listener/system/samba-shares.py) we do a /etc/init.d/samba reload, which also sends a SIGHUP. Maybe we can do a "smbcontrol all reload-config" instead? Some experiments are needed if this a) actually causes smbd to reload the smb.conf and b) if that doesn't trigger the share notification issue reported by the customers.
Created attachment 9179 [details] Patch for bug#44953
This patch would run smbcontrol to tell all (smbd, nmbd, winbindd) processes to reload their config and in the next step it would kill -HUP the nmbd. Also, the reload-config approach doesn't work: ========================================================================= root@master10:~# lsof /var/log/samba/log.smbd COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME smbd 18186 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd smbd 18186 root 12w REG 253,0 10840 531427 /var/log/samba/log.smbd smbd-noti 18205 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd smbd-noti 18205 root 12w REG 253,0 10840 531427 /var/log/samba/log.smbd cleanupd 18206 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd cleanupd 18206 root 12w REG 253,0 10840 531427 /var/log/samba/log.smbd lpqd 18212 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd lpqd 18212 root 16w REG 253,0 10840 531427 /var/log/samba/log.smbd root@master10:~# logrotate -f /etc/logrotate.d/samba gzip: stdin: file size changed while zipping root@master10:~# lsof /var/log/samba/log.smbd log.smbd log.smbd.1.gz root@master10:~# lsof /var/log/samba/log.smbd COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME smbd 18186 root 2w REG 253,0 140 523743 /var/log/samba/log.smbd smbd 18186 root 51w REG 253,0 140 523743 /var/log/samba/log.smbd root@master10:~# lsof | egrep '(18186|18205|18206|18212)' | grep log smbd 18186 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 smbd 18186 root 2w REG 253,0 140 523743 /var/log/samba/log.smbd smbd 18186 root 51w REG 253,0 140 523743 /var/log/samba/log.smbd smbd-noti 18205 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 smbd-noti 18205 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd.1 (deleted) smbd-noti 18205 root 12w REG 253,0 10840 531427 /var/log/samba/log.smbd.1 (deleted) cleanupd 18206 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 cleanupd 18206 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd.1 (deleted) cleanupd 18206 root 12w REG 253,0 10840 531427 /var/log/samba/log.smbd.1 (deleted) lpqd 18212 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 lpqd 18212 root 2w REG 253,0 10840 531427 /var/log/samba/log.smbd.1 (deleted) lpqd 18212 root 16w REG 253,0 10840 531427 /var/log/samba/log.smbd.1 (deleted) ========================================================================= This shows that only the parent smbd reopened the new logfile, but the thre child processes keep on logging into the deleted old logfile, i.e. their log message would get lost. Contrast this with what happens with the postrotate killall smbd solution we currently have: ========================================================================= root@master10:~# lsof +c 15 /var/log/samba/log.smbd COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME smbd 22593 root 2w REG 253,0 1010 523743 /var/log/samba/log.smbd smbd 22593 root 12w REG 253,0 1010 523743 /var/log/samba/log.smbd smbd-notifyd 22604 root 2w REG 253,0 1010 523743 /var/log/samba/log.smbd smbd-notifyd 22604 root 12w REG 253,0 1010 523743 /var/log/samba/log.smbd cleanupd 22605 root 2w REG 253,0 1010 523743 /var/log/samba/log.smbd cleanupd 22605 root 12w REG 253,0 1010 523743 /var/log/samba/log.smbd lpqd 22608 root 2w REG 253,0 1010 523743 /var/log/samba/log.smbd lpqd 22608 root 16w REG 253,0 1010 523743 /var/log/samba/log.smbd root@master10:~# logrotate -f /etc/logrotate.d/samba root@master10:~# lsof +c 15 | egrep '(22593|22604|22605|22608)' | grep log | cat smbd 22593 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 smbd 22593 root 2w REG 253,0 551 524578 /var/log/samba/log.smbd smbd 22593 root 50w REG 253,0 551 524578 /var/log/samba/log.smbd smbd-notifyd 22604 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 smbd-notifyd 22604 root 2w REG 253,0 1295 523743 /var/log/samba/log.smbd.1 (deleted) smbd-notifyd 22604 root 12w REG 253,0 1295 523743 /var/log/samba/log.smbd.1 (deleted) lpqd 22608 root mem REG 253,0 18328 1835187 /usr/lib/x86_64-linux-gnu/samba/liblibcli-netlogon3.so.0 lpqd 22608 root 2w REG 253,0 551 524578 /var/log/samba/log.smbd lpqd 22608 root 16w REG 253,0 551 524578 /var/log/samba/log.smbd ========================================================================= Here only the "smbd-notifyd" subprocess of the main smbd doesn't reopen the new logfile (suspicious!) and the cleanupd exited (oops!), but the lpqd reopened the new logfile. That's far from ideal, but if we change something here, it should really improve the situation. So, I would propose this instead of the killall in the logrotate postrun: pkill -HUP '^(smbd|lpqd)$' This would send the signal only to the main smbd process and the "lpqd" subprocess, which seem to react as expected to it by reopening the new file. It would not send the signal to the "smbd-notifyd", which obviously doesn't react in the desired way. And it also doesn't send the signal to the "cleanupd", which actually exits when a HUP is send to it. As said in Comment 3, we need to experiment with this. It would be good if we can reproduce the original effect reported in the Description of this bug.
Even though I was still not able to reproduce tghat the files are not reloading properly, I applied the proposed fix from Comment 5 (see git branch jahlers/bug44953).
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.