Re: [systemd-devel] Samba Config Reload
On Mon, 11 Apr 2022 at 09:58:54 +0200, Lennart Poettering wrote: > dbus-daemon for example uses: > > ExecReload=/usr/bin/busctl call org.freedesktop.DBus > /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig > > Which is a synchronous call to reload the config: the daemon is told > to reload it, and "busctl call" then waits for the reply before > returning to systemd. ... and, crucially, the implementation of ReloadConfig in dbus-daemon also waits for its own reload to have actually been done (not just put in a queue, but actually done) *before* sending back its reply to the caller (in this case busctl). If you need to wait for something to have happened, then the whole chain of interactions needs to be synchronous: all it takes to break the chain is one component thinking "OK, I'll do that later". smcv
Re: [systemd-devel] Samba Config Reload
On Sa, 09.04.22 19:20, Leon Fauster (leonfaus...@googlemail.com) wrote: > It seems that killing with USR1|USR2|HUP is commonly used: > > $ grep -R ExecReload /usr/lib/systemd/|grep -v kill|wc -l > 19 > $ grep -R ExecReload /usr/lib/systemd/|grep kill|wc -l > 27 Yes. I am aware. It's less than ideal. There are simple services where the synchronous vs. asynchronous reload thing doesn't matter, because there are no services the daemon offers to local clients that might rely on the synchronous execution. But most daemons are probably not like that. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Samba Config Reload
On Sa, 09.04.22 08:00, Yolo von BNANA (y...@bnana.de) wrote: > --- Original Message --- > On Friday, April 8th, 2022 at 13:49, Lennart Poettering > wrote: > > > This could be done better. Plugging in just a "kill" here, means the > > reload is async. i.e. "systemctl reload" will basically return > > immediately without the reload being complete, thus subsequent > > commands can't rely the new config is already in place. > > > > > It's typically nicer to invoke some synchronous command from > > ExecReload=. > > > Can you please explain this in more Detail? > > What does this mean: " "systemctl reload" will basically return > immediately without the reload being complete"? reload-via-SIGHUP means that the ExecReload= will just enqueue the SIGHUP signal in the daemon and immdiately return. The daemon then might take a while before it notices that the signal was queued, and then take a while until it completed the reload. Thus, if you have some script change a config file and then immediately call "systemctl reload" on the relevant service, and immediately expect the setting to be applied, then it might happen that the daemon still hasn't noticed or completed the result. Hence, typically it's better to plug in some tool into ExecReload= that will not just enqueue a reload, but then wait until the daemon reported back that the reload is now complete. > And what is an Example for an synchronous command for ExecReload= dbus-daemon for example uses: ExecReload=/usr/bin/busctl call org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig Which is a synchronous call to reload the config: the daemon is told to reload it, and "busctl call" then waits for the reply before returning to systemd. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Samba Config Reload
Am 09.04.22 um 10:00 schrieb Yolo von BNANA: --- Original Message --- On Friday, April 8th, 2022 at 13:49, Lennart Poettering wrote: This could be done better. Plugging in just a "kill" here, means the reload is async. i.e. "systemctl reload" will basically return immediately without the reload being complete, thus subsequent commands can't rely the new config is already in place. It's typically nicer to invoke some synchronous command from ExecReload=. Can you please explain this in more Detail? What does this mean: " "systemctl reload" will basically return immediately without the reload being complete"? And what is an Example for an synchronous command for ExecReload= It seems that killing with USR1|USR2|HUP is commonly used: $ grep -R ExecReload /usr/lib/systemd/|grep -v kill|wc -l 19 $ grep -R ExecReload /usr/lib/systemd/|grep kill|wc -l 27 Following statement is from $ man 8 smbd Instead of sending a SIGHUP signal, a request to reload configuration file may be sent using smbcontrol(1) program. albeit beforehand they suggest SIGHUP. -- Leon
Re: [systemd-devel] Samba Config Reload
On 09/04/2022 09:00, Yolo von BNANA wrote: Can you please explain this in more Detail? What does this mean: " "systemctl reload" will basically return immediately without the reload being complete"? And what is an Example for an synchronous command for ExecReload= Do you understand the difference between "synchronous" and "asynchronous"? The words basically mean "aligned in time" and "without timed alignment". Think of writing to files. In the old days of MS-DOS et al, when your program called "write", the CPU went off, saved the data to disk, and returned to your program. That's "synchronous", all nicely ordered in time, and your program knew the data was safe. Now, when your linux program calls write, linux itself replies "got it", and your program goes off knowing that something else is going to take care of actually saving the data to disk - that's "asynchronous". Except that sometimes the program needs to know that the data HAS been safely squirreled away (hence all these fsync calls). So when systemd calls ExecReload *A*synchronously, it goes off and fires off a load more stuff, knowing that the ExecReload IS GOING (future tense) to happen. What the previous poster wanted was a synchronous ExecReload, so that when systemd goes off do the next thing, the ExecReload HAS ALREADY HAPPENED (past tense). (Which in general is a bad thing because it *seriously* knackers performance). Cheers, Wol
Re: [systemd-devel] Samba Config Reload
--- Original Message --- On Friday, April 8th, 2022 at 13:49, Lennart Poettering wrote: > This could be done better. Plugging in just a "kill" here, means the > reload is async. i.e. "systemctl reload" will basically return > immediately without the reload being complete, thus subsequent > commands can't rely the new config is already in place. > > It's typically nicer to invoke some synchronous command from > ExecReload=. Can you please explain this in more Detail? What does this mean: " "systemctl reload" will basically return immediately without the reload being complete"? And what is an Example for an synchronous command for ExecReload= signature.asc Description: OpenPGP digital signature
Re: [systemd-devel] Samba Config Reload
On Do, 07.04.22 15:38, Kenneth Porter (sh...@sewingwitch.com) wrote: > --On Thursday, April 07, 2022 12:30 PM +0200 Lennart Poettering > wrote: > > > The other two options are likely similar, i.e. synchronous and talk to > > smbd directly. But I don't know samba that well, so it's just an > > assumption. In fact, if ExecStop= in smbd.service just calls the > > smbcontrol they behave very very similar. > > FWIW, here's the unit file from samba-4.10.16-13 in CentOS 7.9: > … > ExecReload=/bin/kill -HUP $MAINPID This could be done better. Plugging in just a "kill" here, means the reload is async. i.e. "systemctl reload" will basically return immediately without the reload being complete, thus subsequent commands can't rely the new config is already in place. It's typically nicer to invoke some synchronous command from ExecReload=. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Samba Config Reload
--On Thursday, April 07, 2022 12:30 PM +0200 Lennart Poettering wrote: The other two options are likely similar, i.e. synchronous and talk to smbd directly. But I don't know samba that well, so it's just an assumption. In fact, if ExecStop= in smbd.service just calls the smbcontrol they behave very very similar. FWIW, here's the unit file from samba-4.10.16-13 in CentOS 7.9: [Unit] Description=Samba SMB Daemon Documentation=man:smbd(8) man:samba(7) man:smb.conf(5) Wants=network-online.target After=network.target network-online.target nmb.service winbind.service [Service] Type=notify NotifyAccess=all PIDFile=/run/smbd.pid LimitNOFILE=16384 EnvironmentFile=-/etc/sysconfig/samba ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS ExecReload=/bin/kill -HUP $MAINPID LimitCORE=infinity Environment=KRB5CCNAME=FILE:/run/samba/krb5cc_samba [Install] WantedBy=multi-user.target
Re: [systemd-devel] Samba Config Reload
On Mi, 06.04.22 06:21, Yolo von BNANA (y...@bnana.de) wrote: > What is the best way to reload the Samba Configuration – and why? > > 1. systemctl reload smbd > 2. smbcontrol smbd reload-config > 3. pkill -HUP smbd > > I think it's this Order. (1 is best) > But I couldn't explain it to somebody else. I don't know what the "smbcontrol" thing precisely does. So your option 3 is by far the worst. it will kill any process called "smbd" with HUP, even if it has nothing to do with the system service. Moreover, you only want to send SIGHUP to the main daemon process usually, not any children it might have (that likely carry the same name). Moreover, the operation is async: i.e. the reload request is just enqueued and when pkill returns the reload might not even have started yet, let alone completed. THus if you immediately follow with another command, then the changes you made to smb.conf earlier (which I presume is the reason why you want to reload) might or might not have been applied. The other two options are likely similar, i.e. synchronous and talk to smbd directly. But I don't know samba that well, so it's just an assumption. In fact, if ExecStop= in smbd.service just calls the smbcontrol they behave very very similar. If you do things through systemctl it has the benefit that systemd knows about the reload, this is nice because this means systemd can merge multiple reload requests, and you have better state tracking and logs. So yes, the order is correct, i'd say. Lennart -- Lennart Poettering, Berlin
