[systemd-devel] Antw: [systemd‑devel] Antw: [EXT] Re: Samba Config Reload

[Ulrich Windl]

>>> "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de> schrieb am 11.04.2022
um
08:26 in Nachricht <6253CA18020000A100049461 at gwsmtp.uni-regensburg.de>:
> Hi!
> 

Sorry for the typos:

> I thin Lennart had pointed it out: If the sapplication being reloaded does 
s/thin/think/
> not provide any feedback when the reloading is complete, you can never be 
> sure what it did complete.

s/what/when/

> Adding some sleep may catch a grat number of cases whule waiting too long in


s/grat/great/; s/whule/while/

> most cases.
> 
> So before discussing systemd meachnisms: How do you know when reload is 
> complete?
> 
> Regards,
> Ulrich
> 
>>>> Wols Lists <antlists at youngman.org.uk> schrieb am 09.04.2022 um 17:10 in
> Nachricht <fcce76c5‑d376‑bbcc‑10b0‑c325d084ad6d at youngman.org.uk>:
>> 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