launcher: don't fallback to double-forking if systemd-run fails#2965
launcher: don't fallback to double-forking if systemd-run fails#2965jinliu wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adjusts the desktop entry launch flow to propagate a boolean result from the “run as systemd service” code path, and simplifies the systemd-run execution path.
Changes:
- Change
process::runAsyncAsSystemdServiceto returnbooland propagate it to callers. - Remove the systemd-run failure fallback logic inside the systemd service launcher.
- Update desktop entry launch call sites to
returnthe systemd-service launch result.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/system/desktop_entry_launch.cpp | Propagates boolean return value from systemd-service launch path. |
| src/core/process.h | Updates API signature of runAsyncAsSystemdService to return bool. |
| src/core/process.cpp | Implements boolean-returning API and simplifies systemd-run execution (removing fallback). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
9bb1450 to
8fca09c
Compare
|
Hey @jinliu I'd merge it like that but perhaps we should inform the user with a notification toast or something so it's very obvious? Not sure |
Good idea. But that would be like a |
8fca09c to
c4176dd
Compare
Since the systemd-run path is only used on an option which has to be explicitly enabled by the user, if it fails, it's better to just fail the launch, so the user can be aware of the issue. Still fallback to double-forking if systemd is not detected, in case there's a leftover in the config file enabling the systemd launcher on a non-systemd setup. In this case, there's no such option in settings UI, so the user won't even know that the option is enabled, anyway.
d5ab69e to
b14984d
Compare
Since the systemd-run path is only used on an option which has to be explicitly enabled by the user, if it fails, it's better to just fail the launch, so the user can be aware of the issue.
Still fallback to double-forking if systemd is not detected, in case there's a leftover in the config file enabling the systemd launcher on a non-systemd setup. In this case, there's no such option in settings UI, so the user won't even know that the option is enabled, anyway.