Wrong PID set, 'Dropbox isn't running!' when it is.

[AlexChalk]

I suspect this is a bug with the dropbox client, but I don't think the source for that is open so I'm reporting it here.

I'm on linux and running the dropbox daemon as a systemd user service. I interact with the daemon using nautilus-dropbox.

This has worked well, but recently (I'm not sure with which version exactly as the daemon auto-updates) I've started getting 'Dropbox isn't running!' when I try to check the system status with dropbox status.

I see this is determined by checking the PID stored at ~/.dropbox/dropbox.pid:

https://github.com/dropbox/nautilus-dropbox/blob/2852e07cc1cd73bfd948790ac2ea07f4fa94fdad/dropbox.in#L136-L147

The problem is that this PID is incorrect on my machine, it is set to 2 which corresponds to the kthreadd process.

If I manually update the file to the value of systemctl show -p MainPID --value dropbox.service I get unblocked, so I've tried automating this with systemd using a snippet like the following, but without success (the value in the file remains set to 2 when I add this):

ExecStartPost = "/bin/bash -c 'systemctl show -p MainPID --value dropbox.service > $HOME/.dropbox/dropbox.pid'"

Ordinarily, I'd assume this problem is because I'm running the daemon inside systemd, but until very recently this has just worked.

Here is my version info:

Dropbox daemon version: 178.3.4678
Dropbox command-line interface version: 2020.03.04

Let me know if there's any more info I can provide that would be useful to debug this!

[jewelpit]

Oh, that's no good. To get started, could I get the following:

1. Linux kernel version
2. Distro name and version
3. The service file you're using to launch Dropbox
4. Whether you're running against a root or --user instance of systemd (I also run Dropbox as a systemd service, but I run it under --user)

Thanks!

[AlexChalk]

Hi @jewelpit:

1. Kernel: 6.1.37
2. Distro: NixOS 23.05.1622.c99004f75fd (Stoat) x86_64
3. Service file (/etc/systemd/user/dropbox.service):

   
   [Unit]
   Description=Dropbox

[Service] Environment="LOCALE_ARCHIVE=/nix/store/5l0qzzkb3r3yxygdq3688fjcc18lwg3j-glibc-locales-2.37-8/lib/locale/locale-archive" Environment="PATH=/nix/store/f11ibsj5vmqcy8ihfa8mzvpfs4af7cw5-coreutils-9.1/bin:/nix/store/jvh4fbqfxwwn162k5hb8ndc4h5555wfa-findutils-4.9.0/bin:/nix/store/rn5b13lbsslbvmmbqnqxdcagzqp4435w-gnugrep-3.7/bin:/nix/store/w64nwxs3r6cyqgy6ssxib5i2r6k8yfc2-gnused-4.9/bin:/nix/store/8lgs0dqh9ks1164fp4g14gq7w1ihjbf0-systemd-253.5/bin:/nix/store/f11ibsj5vmqcy8ihfa8mzvpfs4af7cw5-coreutils-9.1/sbin:/nix/store/jvh4fbqfxwwn162k5hb8ndc4h5555wfa-findutils-4.9.0/sbin:/nix/store/rn5b13lbsslbvmmbqnqxdcagzqp4435w-gnugrep-3.7/sbin:/nix/store/w64nwxs3r6cyqgy6ssxib5i2r6k8yfc2-gnused-4.9/sbin:/nix/store/8lgs0dqh9ks1164fp4g14gq7w1ihjbf0-systemd-253.5/sbin" Environment="QML2_IMPORT_PATH=/run/current-system/sw/lib/qt-5.15.9/qml" Environment="QT_PLUGIN_PATH=/run/current-system/sw/lib/qt-5.15.9/plugins" Environment="TZDIR=/nix/store/4faw3w020cjxvd1dnxhg73mi10wcxvpw-tzdata-2023c/share/zoneinfo"

ExecReload=/nix/store/f11ibsj5vmqcy8ihfa8mzvpfs4af7cw5-coreutils-9.1/bin/kill -HUP $MAINPID ExecStart=/nix/store/8syxwxayzdyjvnmzb56lng0czkif72qh-dropbox/bin/dropbox KillMode=control-group Nice=10 PrivateTmp=true ProtectSystem=full Restart=on-failure

n.b. Nixos is a bit weird in that you 'declare' the service file in a DSL and it creates it for you:

systemd.user.services.dropbox = { description = "Dropbox"; wantedBy = [ "default.target" ]; environment = { QT_PLUGIN_PATH = "/run/current-system/sw/" + pkgs.qt5.qtbase.qtPluginPrefix; QML2_IMPORT_PATH = "/run/current-system/sw/" + pkgs.qt5.qtbase.qtQmlPrefix; }; serviceConfig = { ExecStart = "${lib.getBin pkgs.dropbox}/bin/dropbox"; ExecReload = "${lib.getBin pkgs.coreutils}/bin/kill -HUP $MAINPID"; KillMode = "control-group"; Restart = "on-failure"; PrivateTmp = true; ProtectSystem = "full"; Nice = 10; }; };

4. User instance

Now that I think about it, the kernel was updated from version 5.15 to 6.1 when I updated from nixos 22.11 to 23.05 a few weeks ago, so that would be my best guess at what's caused this.

Thanks for your help, let me know if I can get you any additional info!

[goffrie]

Good to see a NixOS user, although it's not officially supported by Dropbox ;)

My guess is that this broke because NixOS switched to using bubblewrap in buildFHSEnv (fka. buildFHSUserEnv), which likely uses a PID namespace and therefore dropbox ends up running as PID 2 within its own namespace. I see that the switch from chroot to bubblewrap happened in NixOS 23.05.

Given that I don't think there's much we can do about the PID stuff. We could possibly remove the PID check entirely from the dropbox script. But I'd actually suggest changing the dropbox wrapper in nixpkgs to turn off unshare-pid - just add unsharePid = false; as an argument to buildFHSEnv at https://github.com/NixOS/nixpkgs/blob/8b21af184938793c71936d15965c9afeb1403760/pkgs/applications/networking/dropbox/default.nix#L33

This will also make dropbox's internal limit-to-one-instance check work properly.

[AlexChalk]

Thanks for your help @goffrie, I've made the change you suggested in nixpkgs. I can't control reviewers on the PR but I'd appreciate if you took a look! https://github.com/NixOS/nixpkgs/pull/242332

[AlexChalk]

Someone merged my PR, so once that makes its way into a nixos build this will probably be fixed, but I'll reopen the issue if not. Thanks everyone!