When maestral is running as a system-level systemd service, `maestral status` says that the daemon is not running. about maestral

[seb54000]

I have the same problem, I use multiple dropbox accounts with maestral. I need to be sure the dameon is constantly up for different accounts.
I tried with systemd or also with simple shell scripts that scan the processes and verify fi running, otherwise relaunch.

They all fail in the sense that from CLI it tells me the dameon is not running. If I launch the GUI, it seems to work (can't remember if the GUI relies on daemon or not).

I am also on Ubuntu 22.04. COuld it be related to the fact it is launched by root (through systemd - of course i mention User = seb) ?

In my script shell, I tried :

/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral log level DEBUG -c seb

sudo su - seb -c "DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -c seb"
Starting Maestral...        [OK]

ps -ef | grep -v grep | grep maestral 
seb       660449   58487  0 mars01 pts/0   00:06:05 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -c import maestral.daemon; maestral.daemon.start_maestral_daemon("carole")
seb      3377810   58487  1 09:14 ?        00:00:01 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -c import maestral.daemon; maestral.daemon.start_maestral_daemon("seb")

/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c seb
Maestral daemon is not running.

seb@galaxy-doux:~/ubuntu-desktop$ sudo su - seb -c "DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -c seb"
Daemon is already running.

See above that if I want to start the dameon, it tells me it is already running

Now I also tried in ofregorund with verbose mode (DEBUG)

sudo su - seb -c "DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -f -c seb"
2024-03-02 09:17:58 daemon INFO: Starting daemon
2024-03-02 09:17:58 daemon DEBUG: Environment:
{'DBUS_SESSION_BUS_ADDRESS': 'unix:path=/run/user/1000/bus',
 'HOME': '/home/seb',
 'LANG': 'en_US.UTF-8',
 'LC_ADDRESS': 'fr_FR.UTF-8',
 'LC_IDENTIFICATION': 'fr_FR.UTF-8',
 'LC_MEASUREMENT': 'fr_FR.UTF-8',
 'LC_MONETARY': 'fr_FR.UTF-8',
 'LC_NAME': 'fr_FR.UTF-8',
 'LC_NUMERIC': 'fr_FR.UTF-8',
 'LC_PAPER': 'fr_FR.UTF-8',
 'LC_TELEPHONE': 'fr_FR.UTF-8',
 'LC_TIME': 'fr_FR.UTF-8',
 'LOGNAME': 'seb',
 'MAIL': '/var/mail/seb',
 'PATH': '/home/seb/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin',
 'PWD': '/home/seb',
 'SHELL': '/bin/bash',
 'SHLVL': '0',
 'TERM': 'xterm-256color',
 'USER': 'seb',
 'XDG_DATA_DIRS': '/usr/share/gnome:/home/seb/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop',
 '_': '/home/seb/ubuntu-desktop/maestral-venv/bin/python3'}
2024-03-02 09:17:58 daemon DEBUG: Acquired daemon lock: '/home/seb/.cache/maestral/seb.lock'
2024-03-02 09:17:58 daemon DEBUG: Socket path: '/home/seb/.cache/maestral/seb.sock'
2024-03-02 09:17:58 daemon DEBUG: Creating Pyro daemon
2024-03-02 09:17:58 sync DEBUG: Could not load mignore rules: No such file or directory
2024-03-02 09:17:58 daemon DEBUG: Starting event loop
2024-03-02 09:17:58 manager INFO: Connected
2024-03-02 09:17:58 sync DEBUG: Could not load mignore rules: No such file or directory
2024-03-02 09:17:58 dropbox_client DEBUG: Refreshing access token.
2024-03-02 09:17:59 dropbox_client DEBUG: Request to users/get_space_usage
2024-03-02 09:17:59 manager DEBUG: Checking path root...
2024-03-02 09:17:59 dropbox_client DEBUG: Request to users/get_current_account
2024-03-02 09:17:59 manager DEBUG: Path root is up to date
2024-03-02 09:17:59 sync INFO: Fetching remote changes
2024-03-02 09:17:59 sync DEBUG: Fetching remote changes since cursor: AAHXavOXwQr1mUszxzO7Lr-rG2xL1XwtBc6rpYJ4nVqJVXmPsynWHUU47ikNJuWwJ8sm-1YuMxeskAvQmpAntxQ1llCeA-KJFW4wOUl2y0a2uZ8OYA3ztDolx8mrJpcc8gI1a2XwkE-zby5xHkSfZRS3QVRk_Kl4Xki4NS-GUIkgYrVM7pxWJw1Wsg_mZfP6zVPVVPfM_xuxBBn7cWTF_oT4o7WdO-1nk5TF7mrm5UnF01xKP_0lXHuuQ6toCJ2ubhJB-V9gBgQV5tiVrmf9NAUz-i37fPwEFnTHwIIIFR_1O-t9lzzNa-brBb5oSl-JYmYeTPjpaaLaQ1hwNlic0t01-KodV0pmVDNiXAIecazLRDwawtE91COWYgn8uqmY3W8L_G9xug8DhRHx5ha8VeHw-P2vx4CGU-ITk4F6pXHsw5p7PMG89OSG2CxrKSG0bQt4g92FNQzSQ3T0HqoVHMbHFsIX3ivP_Um8w2wnKUkTlg
2024-03-02 09:17:59 dropbox_client DEBUG: Refreshing access token.
2024-03-02 09:17:59 dropbox_client DEBUG: Request to files/list_folder/continue
2024-03-02 09:18:00 sync DEBUG: Remote changes:
[]
2024-03-02 09:18:00 sync DEBUG: Converted remote changes to SyncEvents
2024-03-02 09:18:00 sync DEBUG: Remote cursor saved: AAEWcGXfRjx-ATL85Gvz7Os0CbkWdKrrNLSlE_KAZv85s9McbEO14rTPQiPXJY1OB8ndiYsdoQ_oPb5E49Ug-xP9xv1-EPtRuNTfvmIdAlpTN3pG4YgkD3auaTiI1ekJYz32hRPnDs95aPNHzaBH-9LWjSRItWIEu7mPrU7KFSmD8xHY6Q2KuoYqsMCDJFkNTg28C0PUOauZRxdsDvLXs9Bnh8VDgtyIoa99rxLxZaVZ514m3GY2PHUU-W4wKuk8dfuExZEuU3vqRfWY_T3LsL7B40nWuSd60bHFDA6nJcwN2PWb6Icmr_q9gR2LoB3dBZX_VT0IGFN2B-SqNNfVn0jqOOmdnT6kfOXAIHdzLKC1ZDfchDYe9KRz5LlXQXrhx0m_ZwWETksR6hl4d83Ote2LjMdey2ZlU4BbJCuJOhPOguoIp9HPqFWpbUn38JJJ0T3WPPOqU1SfEdkl9FmSSBBdOr1ZurWKUjRQxHH09eUIxQ
2024-03-02 09:18:00 sync DEBUG: Pruning sync errors
2024-03-02 09:18:00 sync INFO: Indexing local changes...
2024-03-02 09:18:00 sync DEBUG: Local indexing completed in 0.1116 sec
2024-03-02 09:18:00 sync DEBUG: Retrieved local changes:
[]
2024-03-02 09:18:00 sync DEBUG: No local changes while inactive
2024-03-02 09:18:00 sync DEBUG: Local cursor saved: 1709367480.1581585
2024-03-02 09:18:00 manager INFO: Up to date
2024-03-02 09:18:00 sync DEBUG: Waiting for local changes since cursor: 1709367480.1581585
2024-03-02 09:18:00 sync DEBUG: Waiting for remote changes since cursor:
AAEWcGXfRjx-ATL85Gvz7Os0CbkWdKrrNLSlE_KAZv85s9McbEO14rTPQiPXJY1OB8ndiYsdoQ_oPb5E49Ug-xP9xv1-EPtRuNTfvmIdAlpTN3pG4YgkD3auaTiI1ekJYz32hRPnDs95aPNHzaBH-9LWjSRItWIEu7mPrU7KFSmD8xHY6Q2KuoYqsMCDJFkNTg28C0PUOauZRxdsDvLXs9Bnh8VDgtyIoa99rxLxZaVZ514m3GY2PHUU-W4wKuk8dfuExZEuU3vqRfWY_T3LsL7B40nWuSd60bHFDA6nJcwN2PWb6Icmr_q9gR2LoB3dBZX_VT0IGFN2B-SqNNfVn0jqOOmdnT6kfOXAIHdzLKC1ZDfchDYe9KRz5LlXQXrhx0m_ZwWETksR6hl4d83Ote2LjMdey2ZlU4BbJCuJOhPOguoIp9HPqFWpbUn38JJJ0T3WPPOqU1SfEdkl9FmSSBBdOr1ZurWKUjRQxHH09eUIxQ
2024-03-02 09:18:00 dropbox_client DEBUG: Request to files/list_folder/longpoll

2024-03-02 09:18:40 sync DEBUG: Waiting for local changes since cursor: 1709367480.1581585
2024-03-02 09:18:53 sync DEBUG: Detected remote changes: False

THen on another shell

ps -ef | grep -v grep | grep maestral
seb       660449   58487  0 mars01 pts/0   00:06:06 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -c import maestral.daemon; maestral.daemon.start_maestral_daemon("carole")
root     3385868 3156792  0 09:17 pts/0    00:00:00 sudo su - seb -c DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -v -f -c seb
root     3385869 3385868  0 09:17 pts/1    00:00:00 sudo su - seb -c DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -v -f -c seb
root     3385870 3385869  0 09:17 pts/1    00:00:00 su - seb -c DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -v -f -c seb
seb      3385871 3385870  4 09:17 ?        00:00:00 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -v -f -c seb

/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c seb
Maestral daemon is not running.

Last test is to show that I can launch 2 daemon (one with duso command as seb user and the other one directly as seb and now it works). The dameon launched through sudo (but as user seb) seems like a zombie that is not reachable from the CLI as user seb.

seb@galaxy-doux:~/ubuntu-desktop$ sudo su - seb -c "DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -c seb"
Starting Maestral...        [OK]

seb@galaxy-doux:~/ubuntu-desktop$ /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start -c seb
Starting Maestral...        [OK]

seb@galaxy-doux:~/ubuntu-desktop$ ps -ef | grep -v grep | grep maestral 
seb       660449   58487  0 mars01 pts/0   00:06:10 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -c import maestral.daemon; maestral.daemon.start_maestral_daemon("carole")
seb      3418664   58487  5 09:31 ?        00:00:00 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -c import maestral.daemon; maestral.daemon.start_maestral_daemon("seb")
seb      3419044   58487 17 09:32 pts/0    00:00:00 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -c import maestral.daemon; maestral.daemon.start_maestral_daemon("seb")

seb@galaxy-doux:~/ubuntu-desktop$ /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c seb

Account      seb (Basic)  
Usage        39.3% of 5.2 GB used                   
Status       Up to date                             
Sync errors  0  

If you have any idea, it would be very much appreciated

[seb54000]

Please note that if I don't define the DBUS_SESSION_BUS_ADDRESS env var, I got an error when launching maestral with sudo (or systemd) complianing about the fact that this var is undefined (so I did an echo of this var in my usual seb session and define it while sudoing or in systemd through Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus)

[samschott]

I suspect the issue lies with where the socket for communication with the daemon is created, and where later commands are searching for it.

In the debug output which you posted, the following two lines show the locations of the lock file and socket for the daemon instance:

2024-03-02 09:17:58 daemon DEBUG: Acquired daemon lock: '/home/seb/.cache/maestral/seb.lock'
2024-03-02 09:17:58 daemon DEBUG: Socket path: '/home/seb/.cache/maestral/seb.sock'

Those are the files that any CLI command will search for to detect and connect to a running daemon for the 'seb' config.

I suspect that starting the daemon from systemd at boot, with a config stored in /etc/systemd/system/ will result in different paths being used here, despite specifying the user in the systemd config file. Could you similarly inspect the log files of the daemon created at boot?

It may be possible to explicitly specify XDG paths to be used in the systemd config, to ensure that the user's directories are used.

[seb54000]

Hi @samschott , thanks a lot for taking time to dig this issue.
I don't know why but I'm struggling a lot to make the systemd service work again. Actually I have errors like [email protected]: Got notification message from PID 2967056, but reception only permitted for main PID which is currently not ...

I will manage that (I'm alos not comfortable to set the DEBUG mode while in ssytemd as it is a command to pass, there is no env var to set the debug mode ?)

Anyway, I'm just asking regarding your question that I also reproducing the problem without systemd. The DEBUG logs you mention are using the foreground mode (that help me to show the logs). When I do that with sudo su - seb -c we can then see the usage of lock: '/home/seb/.cache/maestral/seb.lock'

Still if I do a status it doesn't work. So my point is that even when the lock is "correctly" set, I still have the Maestral daemon is not running. message

Reference to my detailed post :

• part with the debug log
• just below the debug, "Then on another shell" part

Again thanks a lot for your help, I will update this post as soon as I manage to make systemd work again

[seb54000]

Hello again @samschott , seems you were on the right track with the PATH, I maange to find that the lock file is located in : /run/user/1000/maestral/seb.lock while running with sudo or with systemd (maybe becaus of the DBUS var) while it is in /home/seb/.cache/maestral/seb.lock when running as my user

uid of my user seb is of course : uid=1000(seb)

I don't know how to tell maestral to specify a different PATH for lock file. At least I can call maestral everytime specifying the DBUS var and it seems to work :

sudo su - seb -c "DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c seb"

Account      [email protected] (Basic)  
Usage        40.7% of 5.2 GB used                   
Status       Up to date                             
Sync errors  0

So now, I need to make systemd maestral service work again.

@jcherniak can you check that it is working for you ? I mean, you have to find the lock file location whe running as sytemd (maybe in /var/run like me)

[samschott]

On Linux, Maestral uses different paths depending on environment variables:

Lock file: $XDG_RUNTIME_DIR/maestral/{config_name}.lock
Socket: $XDG_RUNTIME_DIR/maestral/{config_name}.sock

In your case, you could for example explicitly provide environment variables in the systemd file:

[Service]
Environment="XDG_RUNTIME_DIR=/home/seb/.cache"

You might run into trouble through with ~/.cache being deleted when the user logs out from their last session. Typically, systemd user instances are started after the first login of a user and killed after the last session of the user is closed, matching the lifecycle of XDG_RUNTIME_DIR for that user, but its possible to deliberately set this up differently. See https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances.