Thought maybe it was a Wayland thing, but same issue happen on X11 as well.
Installed Stacer to see if making Dropbox as startup entry, and that didn’t help either.
I think the problem (that I also saw on my system) is that the autostart service unit, that the systemd xdg autostart generator creates automatically, assumes that any autostart application you register is an actual application - i.e. the process runs and the application is active and when the process ends - the application exits. This causes a problem for applications like Dropbox (and other similar things - I also use insync which is another file sync service and it also has the same problem):
- The command you run to start the service is a short lived one - it sets things up then starts a daemon to do the actual work, then exits.
- A systemd unit has its own runtime scope (it’s a systemd thing based on cgroup) and when the main process ends - correctly or not - it closes the scope, which kills any processes that were in the scope. This is a feature that is meant to prevent runaway zombie precesses from consuming resources.
When systemd closes the scope for app-dropbox@autostart.service because the dropbox start command ended, it kills the Dropbox sync daemon.
On my system setting an override file that changes the autostart service execution type to “forking” instructs systemd to watch the main command and see that it “forks” (executes a child process) and if it does, then that child process - the daemon - is the main process and the scope lifetime will be tied to it, and this fixed the problem for me.
BTW - when you launch the Dropbox starter from the application launcher, its not in its own systemd service, instead it runs in the Plasma shell scope, which is why it can survive.
In your logs we can see that systemd considers the process as “started” (i.e. the “starting” has completed) before the daemon forks - which means it didn’t understand what I wanted it to understand.
I’ll need to look into it a bit more, but I will only be able to do it later tomorrow.
From what i can understand… problem should not exist on MX Linux (non-systemd) but why it works on SpiralLinux (systemd) is another question.
In the meantime, getting used to starting Dropbox via app icon on panel.
Hopefully if a solution comes around, it will be, just as you said, helpful to others.
I looked at it a bit more and managed to reproduce the issue. With the configuration snippet you showed in your screenshots from yesterday, I expect the Autostart module will show in the entry log the message:
Failed to parse service type, ignoring: Forking
Because that is a typo. Setting the override.conf file to:
[Service]
Type=forking
Should fix the problem - note the lower-case “f” in “forking”.
2 Likes
By George, i think you’ve got it! 
Just rebooted and Dropbox was there! yay!
Thanks a bunch, and tell your wife she found a good guy! 
Think i’ll wait 'till tomorrow to mark thread as “solved”.
BTW - this apparently had already been fixed in the future: On current Neon stable we are running on systemd 249. In systemd 250 they added a feature called “ExitType” and the systemd autostart generator uses it and sets it to the non-default value “cgroup” - which means that the service unit is done and should be closed only when all processes in the cgroup (control group) have completed - which means it must wait for the Dropbox daemon, and that would solve it for the next version of Neon - without the need for creating override files.
2 Likes
After 6.1 'cause upgrading to it today, didn’t resolve the issue.
Sorry that I wasn’t more clear - when I said “next version of Neon”, I didn’t mean the next version of Plasma, I mean an updated Neon system that is based on an updated Ubuntu 24.04. It is in the works and will hopefully be done in time for Plasma 6.2.
I may well be the guy who had this issue too that you’re referencing. I went to Dropbox’s forum for help and was told to remove any autostart entries for Dropbox as it has its own autostart mechanism. What was happening to me is that it wanted to reconnect my computer every time I logged in - it was autostarting twice and that confused it.
I’ve found that if I leave Dropbox to do its own thing and not create systemd services for it or allow KDE to create an autostart entry, it works, syncs and starts up fine.
This is on Fedora though, not Neon or Ubuntu. Not sure if any of this helps but it’s here for posterity.
That is very interesting. Do you know how Dropbox autostarts itself with XDG Autostart? It doesn’t do so on my system.
After brief tryout with MX 23.3 KDE iteration, with no problems there for Dropbox to autostart, came back to KDE Neon, and it still won’t autostart.
Time for a bug report?
Operating System: KDE neon 6.0
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.0
Kernel Version: 6.5.0-41-generic (64-bit)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-8500 CPU @ 3.00GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630
Manufacturer: Dell Inc.
Product Name: OptiPlex 7060
This is likely the difference in the systemd version. There’s not point in reporting this but as it was already reported and fixed.
You mean, KDE Neon fixed it with 6.1.1 ?
Btw, have previously tried a few other distros (Mint, Q4OS, Lite and more) without Dropbox startup issues.
As I’ve noted above, it’s a systemd bug that was already fixed in systemd. It isn’t a bug in KDE. Neon will fix this in the port to the 24.04 LTS that will be released around August.
Okay.
Will see you in August. 
For the record.
While MX is systemd free (at least by default), the others are not.
I created an account just to mention how grateful I am to you. I’ve been trying to hunt down this issue for literal YEARS (from Ubuntu, Pop!_OS and now Neon) with no actual resolution to startup not working for Dropbox.
Adding the forking override.conf with the “forking” type fixed the startup issue for my particular case as I’ve installed via deb. Even though it would have been pushed in the August update, I’m just glad to know what it was that caused the issue that was driving me crazy!
1 Like
KDE Neon 6.2 has finally resolved this issue.
A bit late in the game there bud.
Case was resolved with Plasma 6.2
FYI, MX Linux (and others like SpiralLinux) did not have this issue.
It was only a KDE Neon problem (not a Dropbox one).
@daniboi as discussed in the thread, the issue was with systemd and is fixed by updating to Neon noble (which coincidentally came out at the same time as Plasma 6.2) that comes with the fixed systemd version.
The problem wasn’t exhibited by a default install of MX Linux, as that isn’t using systemd by default, but I believe that if you had enabled systemd on MX Linux (which is supported, according to the docs) you would have ran into the same problem.
Have never run MX as systemd, so cannot attest to this.
But…
LinuxMint, Q4OS, SpiralLinux run systemd right?
Distros that i have tried without Dropbox startup issues.