vorta
vorta copied to clipboard
Vorta Crashes When Launched With --daemonize
I've seen this happen now with two different macOS devices (Big Sur and Monterey), so I'm fairly certain that --daemonize is broken on Macs. When launched via terminal running /Applications/Vorta.app/Contents/MacOS/vorta-darwin --daemonize
I get the result below. Also running it via open /Applications/Vorta.app --args --daemonize
appears to crash, but there is no output.
objc[27774]: +[NSPlaceholderString initialize] may have been in progress in another thread when fork() was called.
objc[27774]: +[NSPlaceholderString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
Running Vorta without --daemonize works fine in both above examples.
What additional details do you require?
Can reproduce. Maybe os.fork()
doesn't work on macOS any more? It's not really needed when using the bundled app package. I believe we added it for Flatpak.
If there is a better way to do the same thing that still works on Linux and doesn't add much code, we can consider adding it: https://github.com/borgbase/vorta/blob/b6a24debb78b953117a3f637db18942f370a4b85/src/vorta/main.py#L47-L55
My guess is that this is related to System Integrity Protection introduced with Big Sur. Did a bit of searching and found other devs running into issues with fork() that was tied to SIP. All I'm trying to do is launch Vorta for the first time without displaying the UI. I have a script that I'm pushing out via an MDM that does the following:
- Generates an SSH key specifically for backing up.
- Uploads the SSH key to borgbase via the API.
- Creates a new repository for the device via the borgbase API.
- Initializes the repository.
- Downloads a config file and swaps out default values with SSH, repo and passphrase and bootstraps Vorta.
- Launches Vorta as the user, ideally while suppressing the UI.
Interesting use case. We already have others doing similar things. The guy who added the profile import feature for example.
The --daemonize
option was added to disconnect Vorta from the current shell. Not exactly what you need anyways. Maybe making sure the "No GUI" setting is applied during config import or a --no-gui
option is more appropriate
Ah yes, thank you. The foreground option in the config should work. Cheers.
The python multiprocessing
module bypasses the problem with fork by using the spawn method for starting a new process. Maybe vorta could somehow leverage their implementation or use a simpler one for the same method.
The user can work around the problem by setting the environment variable OBJC_DISABLE_INITIALIZE_FORK_SAFETY
to True
.