Control syncthing daemon executable from tray action #48
Comments
|
I think I'm having an issue related to this, when I use ControlPlane to "switch context" for my laptop. Upon leaving a context, I would have ControlPlane to "quit" the app. I don't really know what signal it sends to "quit" the app, but I noticed for now it seems to just "kill" the main app process Would love to see this being implemented. Please let me know if I can do some testing because I'm afraid I can't help with the actual development :( |
|
Yes I have also observed this bug, the wrapper sometimes loses track of the running |
|
Not a problem! I'm thankful for people like you who work on open-source projects for the sake of many others. Just let me know if I can help with testing! |
|
As soon there is some progress you get notified in this issue. |
|
So currently it's a fairly fire-and-forget sort of setup. If Syncthing doesn't launch we'll never know, if we crash it'll stay running in the background, and it uses the standard monitoring process for restarts etc. I think we should do the work of the Syncthing monitor process ourselves here and manage restarts etc., and make visible the daemon state somehow in the UI. The one abnormality that I think would be worth handling is if Syncthing exits or can't be started, yet is reachable via the API. This happens if it's already running in the background for example - we can't start it again, but we can talk to it. This should be a success scenario, and when we can no longer talk to it over the API we should try starting it again. (Or maybe try starting it periodically regardless.) I can try to tackle this if noone objects. |
|
Yes this is indeed FAF. Because I initialy started the project for personal use it worked fairly well. But those corner cases where stuff is not working should be handled in a convient way. When putting it out in the wild and more people going to actual install it on their computer. |
|
Fixed in #71 |
|
@calmh I have updated using the auto-updater. It seems it then loses track of the child process and the upgraded wrapper restarts every now and then the background service. I'm not sure but I think we can't do much, except rethink how we could kill spawned and detached background service instances. Maybe we should track the PID from the NSTask and store it, on startup when it stops after trying to bind we should try to kill the instance of the PID we stored earlier? |
* syncthing/Scripts/syncthing-resource.sh: Bundle with 0.14.47 * Get rid of syncthing/Scripts/syncthing-inotify-resource.sh as filesystem change notifications are builtin to syncthing since v0.14.47 * Delay reconnect attempts if the server returned an error (#47) This should fix high CPU usage issue when API key is invalid. Partial fixes #46. * Bump syncthing resource to v0.14.48 (#55) * syncthing/STApplication.m: Sort folders submenu ascending (fixes #49) (#53) * syncthing/STApplication.m: Sort folders submenu ascending (fixes #49) * syncthing/STApplication.m: Fix review comment of @virusman * Use CocoaPods for Sparkle framework dependency (fixes #57) (#60) * Update syncthing resource to v0.14.49 (#64) * Update syncthing resource to v0.14.49 * syncthing/Scripts/syncthing-resource.sh: Use new tarball name * Adjust event request timeout (fixes #65) (#66) This sets the event request a bit longer and, more importantly, informs Syncthing of the timeout. The result is that the request returns successfully without events, and we don't get a timeout error. * Refactor HTTP(S) handling (fixes #24) This moves event getting into the XGSyncthing library, while also refactoring it to use NSURLSession, a delegate for allowing local TLS certificates, and proper parameters. The delegate simply skips HTTPS certificate checking on hosts called "localhost", "127.0.0.1", or "::1". I think this is what most people would want from this tool. * Remove #24 from README too * README.md: Update to use new URLs (#67) Also add @calmh to AUTHORS.md * Move LocalhostTLSDelegate files accidentally committed at root (#70) * Generate appcast.xml from github releases (#63) * script/ghreleases2appcast.go: Initial working github releases to sparkle framework appcast.xml converter (resolves #62) * Activate existing windows for About/Preferences (fixes #72) (#73) * Add daemon process handling (fixes #48) (#71) * Add new submenu with status of the syncthing service * Cleanup some code * Copy executable from bundle (fixes #37) (#76) This copies the bundled executable before executing it, if the target executable doesn't already exist. This has several desirable properties: - We do not mess up the application bundle by letting Syncthing upgrade - The user can revert an undesired upgrade by deleting the binary and restarting the wrapper. The binary is stored in ~/Application Support/Syncthing-macOS because I don't want to put it in Syncthing's config directory. That directory is in principle managed by Syncthing and we can't be sure it won't be removed or something. * Prepare for v0.14.49-1 release (#75) * syncthing.xcodeproj/project.pbxproj: Rename PRODUCT_BUNDLE_IDENTIFIER for Sparkle updater (see #74) (#79) From com.github.syncthing.syncthing-macos back to com.github.xor-gate.syncthing-macosx to fix Sparkle update issue in #74. * script/ghreleases2appcast.go: Use working blackfriday.v1 (see #77) (#78) * script/ghreleases2appcast.go: Changes for upgrades.s.n deployment (#80) Basically, don't alter the download URLs for now, indent the XML for readability. * Fixup project move leftovers and update some documentation (#81) * Fixup project move leftovers and update some documentation and contributing * Cleanup xcode project with useless xgsyncthing target * README.md: Add note about homebrew cask (ref #23) * readme: Update contribution guidelines link (fixes #83) * Bump syncthing resource to 0.14.50 * Use latest syncthing v0.14.51 resource * CocoaPods: Manual patch EXPANDED_CODE_SIGN_IDENTITY: unbound variable #7708 bug * Use syncthing v0.14.52 resource
Currently it is not possible to control the syncthing subprocess with start/stop/restart actions. Also we must sure we don't lose track of the subprocess.
The text was updated successfully, but these errors were encountered: