It shouldn't be a service
Something that can't be terminated without causing catastrophic damage to its operation shouldn't be run as a "service", but as a per-job script or process.
What you're attempting would compare to waiting for the Internet to stop requesting from your website before allowing
systemctl stop apache2 to complete itself.
For a local machine, if you need to shut down the machine, you won't be able to continue writing the file anyway. If you decided to do that, then you want
systemctl to end the service without waiting.
Maybe, your service should run another script that waits to terminate.
The solution will be in your Product Roadmap, viz letting the developers tell the Product Manager what user experience isn't possible and what the user should experience instead.
I'm answering this with the following suggestions, not knowing the contents of your script
hltv_start.sh because you didn't share it. So, it must not be central to your question. Accordingly, I can't be specific much beyond these brainstorms...
- Take a scripted approach to what Kdenlive does in GUI, similar to to the option of shutting down the machine once finished rendering. You could adapt a scropt to start writing your file, then automatically shut down your service via
systemctl stop after you finish writing your file.
- Make a script to write your file on a per-job basis using
wait to let the write process finish before exiting.
- Write a separate script using
systemctl to end that process is a kind of power-move that should stop the process mid-file.
- If you need a service involved, use it to "listen" or something, not to actually write—a service that calls a script that uses
wait to end, if even necessary.
- If the service only "listens", then runs another script that writes your file using
wait, then you could theoretically
systemctl stop your service while allowing the write operation to finish, which I think is your goal.