### System details

Ryzen 5600x with 3060 12gb and 32 gb of ram 

### What's wrong?

Dropbox account linking does not complete on Omarchy because the generated
`[email protected]` kills the Dropbox daemon shortly after startup.

The Dropbox browser authentication flow opens successfully, but the local
Dropbox daemon is terminated before it can complete the linking process and
create `~/.dropbox/info.json`.

As a result, the Omarchy Dropbox panel continues to show:

> Login to Dropbox
> Start the authentication flow

even after successfully logging in through the Dropbox website.

## Environment

- Omarchy: 4.0.3-1
- Hyprland: 0.56.2
- Dropbox package: 264.4.3421-1
- Self-updated Dropbox client: 268.4.4124
- Architecture: x86_64
- Wayland

## What happens

1. Dropbox is installed and started through Omarchy.
2. The Omarchy Dropbox panel shows `Login to Dropbox`.
3. Clicking the login flow opens a Dropbox `cli_link_nonce` URL in the browser.
4. The Dropbox website login/account connection completes successfully.
5. However, the local Dropbox daemon is killed before the authentication state
   is written locally.
6. `~/.dropbox/info.json` is never created.
7. The Omarchy panel therefore continues to report the account as unauthenticated.

Running:

```bash
dropbox status

results in:

Killed
Exit code: 137
Evidence

The packaged Dropbox client and self-updated client are different versions:

pacman Dropbox package:
264.4.3421-1

~/.dropbox-dist/VERSION:
268.4.4124

The running process is the self-updated client:

/home/abhra/.dropbox-dist/dropbox-lnx.x86_64-268.4.4124/dropbox /newerversion ...

The generated systemd service is:

[email protected]

and uses:

Type=exec
ExitType=cgroup

The service starts:

/usr/bin/dropbox

The packaged /usr/bin/dropbox acts as a wrapper which launches the newer
self-updated Dropbox daemon from ~/.dropbox-dist/ and then exits.

Because the generated service uses:

ExitType=cgroup

the daemon launched by the wrapper remains inside the service cgroup.

When the wrapper exits, systemd subsequently terminates the remaining processes
in that cgroup, including the actual Dropbox daemon.

Observed behavior is consistent with the daemon surviving for only several
seconds before receiving:

SIGKILL

The service status shows:

Main PID: ... (code=killed, signal=KILL)

and the daemon subsequently disappears.

Authentication evidence

During the login attempt, the Dropbox CLI generates a URL such as:

https://www.dropbox.com/cli_link_nonce?nonce=...

The URL is successfully opened in the browser and the Dropbox website allows
the account connection.

However, the local authentication state is not completed because the daemon
is terminated.

~/.dropbox/info.json is absent, while the Dropbox database files under
~/.dropbox/instance1/ remain present.

dropbox-cli status reports that Dropbox is waiting to be linked.

Why the Omarchy panel remains on "Login to Dropbox"

The Omarchy Dropbox status code determines authentication using the local
Dropbox account information.

In particular, it checks whether the account path exists:

authenticated = account_path != "" and Path(account_path).exists()

Because the local account-linking state is never completed, the panel
continues to display the login button.

The panel therefore appears to be behaving consistently with the local state;
the underlying failure is that the Dropbox daemon does not survive long enough
to complete authentication.

Root cause

The current generated systemd service appears incompatible with Dropbox's
wrapper → self-updated-daemon architecture.

The problematic sequence is:

[email protected]
        |
        v
/usr/bin/dropbox
        |
        v
self-updated Dropbox daemon
~/.dropbox-dist/.../268.4.4124/dropbox
        |
        v
wrapper exits
        |
        v
ExitType=cgroup
        |
        v
Dropbox daemon receives SIGKILL
        |
        v
OAuth linking cannot complete
        |
        v
~/.dropbox/info.json not created
        |
        v
Omarchy panel still shows "Login to Dropbox"
Related issues

This appears related to existing Dropbox/systemd integration reports,
particularly the issue concerning the Omarchy Dropbox panel starting
dropboxd without the same process/session handling used by the installer.

It may also be related to reports of dropbox / dropbox-cli commands being
terminated with Killed.

However, the important difference here is that the failure was reproduced
locally and the generated systemd service's ExitType=cgroup behavior appears
to explain why the daemon is killed after the wrapper exits.

Expected behavior

The Dropbox daemon launched through the Omarchy/systemd autostart path should
remain alive after /usr/bin/dropbox hands off to the self-updated Dropbox
client.

The browser authentication flow should be able to complete and create the
normal local Dropbox account state.

The Omarchy panel should then detect the account as connected.

Request

Please investigate whether the generated:

[email protected]

should use a service lifecycle compatible with Dropbox's wrapper/self-updater
architecture.

In particular, please consider whether:

ExitType=cgroup

is appropriate when /usr/bin/dropbox launches a separate self-updated daemon
and then exits.

A possible direction may be to ensure that the actual Dropbox daemon is not
killed when the wrapper process exits, while preserving normal systemd
lifecycle management.

I have not modified Omarchy package-owned files or the Dropbox installation
while investigating this issue.

No Dropbox data was deleted or reset