Hi! I thin Lennart had pointed it out: If the sapplication being reloaded does not provide any feedback when the reloading is complete, you can never be sure what it did complete. Adding some sleep may catch a grat number of cases whule waiting too long in most cases.
So before discussing systemd meachnisms: How do you know when reload is complete? Regards, Ulrich >>> Wols Lists <[email protected]> schrieb am 09.04.2022 um 17:10 in Nachricht <[email protected]>: > 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
