On Obisidian Quits-Event not working?

[hornhaut]

Hi,

I start a service on a port on obsidian start, and I want to kill that service when obsidian quits. In PowerShell when I execute
Stop-Process -Id (Get-NetTCPConnection -LocalPort 18081).OwningProcess -Force
it works perfectly, but shell commands does not seem to be executed on obsidian quit. I already checked “Ask for confirmation before execution” but I also do not get the prompt and configured it to run in PowerShell 5 on Windows.

Does anyone experience the same issue, or did I just configure the command wrong?

Best,
Sebastian

[Taitava]

Ah, Ask for confirmation before execution doesn't work well when used with the Obsidian quits event. I never came to think about using those two together, maybe I should add some tip to docs about not to use them together, or even disable turning both on if one of them is on already.

The problem is that when Obsidian quits, there's AFAIK no way for plugins to postpone (or cancel) closing the application. Obsidian just closes and tries to inform plugins about the closure, but even the informing is not guaranteed. This leads to a situation where the Obsidian quits event triggers your shell command, but as the confirmation setting is on, a confirmation dialog is tried to be opened - but that doesn't happen because Obsidian has already quit before the dialog has any time to show up.

(The same applies for Prompts, too, that could be used in place of the confirmation setting, although I guess you are not using them here.)

So:

1. Turn off Ask for confirmation before execution.
2. I'm not very experienced with PowerShell, but if the confirmation is absolutely necessary, you could explore if there's a way to open some graphical window in PowerShell that would ask for a confirmation before continuing to execute your command.
3. If the shell command still does not work when quitting Obsidian, can you please narrow down the problem by trying some other shell command. It needs to be something that does not provide output (as there's no time to process output when Obsidian is quitting), but you should be able to see that it does something, so I guess some simple file writing would be the best.

Please let me know if this helped at all, or if you still have problems or questions. 🙂

[hornhaut]

Thank you! I also tested it without prompting. Prompting was more like an attempt to check whether the command is executed at all. I see that this can't work in Obsidian. I'll try simple file writing and see what's happening :)

[Taitava]

Ok, so the problem is not yet solved. Did you also try executing the command from Obsidian's Command palette? Just to narrow down the problem, is the problem in the quitting event or somewhere else.

[hornhaut]

sorry, got delayed with testing :/ running commands from the command palette seems to work. At least when I kill my service I can restart it without error messages (it returns a message that there already is a service running on this port when the service is already running). I also tried to open a PowerShell window on the Obsidian quits event, which also is not executed (but works from the command palette). So maybe I need to change my approach and check if the service is already up on obsidian startup and then just not start it on.

[Taitava]

No problem 🙂. One more thing came to my mind. I'm not certain, but it might be that on Windows, processes launched from Obsidian get killed when Obsidian quits.

From https://nodejs.org/api/child_process.html#optionsdetached:

On Windows, setting options.detached to true makes it possible for the child process to continue running after the parent exits. The child will have its own console window.

The SC plugin uses Node.js's child_process.spawn() to execute shell commands. I haven't done much testing on what happens to the plugin's launched processes after Obsidian quits. But according to the above statement, it might be that processes get shut down when Obsidian quits. I haven't used the mentioned detached option at all in this plugin, but I might consider testing it and adding a setting for it if the test shows any benefits.

I need to do create a long running process and test if it shuts down on Windows when Obsidian quits, and if I can then make it not to shutdown by using the detached option. If that test succeeds, then I can make it a setting and release as a feature.

I might also consider making the Obsidian quits event always execute shell commands with the detached option set automatically on, but that depends on what kind of side effects it will have, at least The child will have its own console window is mentioned.

I'll come back to this when I have tested this, but it will take some time, as I have #108 in progress right now.