When maestral is running as a system-level systemd service, `maestral status` says that the daemon is not running.
jcherniak opened this issue · 10 comments
Summary
When maestral is running as a system-level systemd service, maestral status says that the daemon is not running.
Describe the bug
I wanted to set up maestral on a backup server box to store a copy of my Dropbox repo. maestral autostart sets up a user-systemd service, but unfortunately that will only start on login.
I'm on Ubuntu 22.04 and installed maestral under my user using pipx
As such, I created the following file in /etc/systemd/system/maestral-daemon@maestral.service so that it would start on boot
[Unit]
Description = Maestral daemon for the config %i
[Service]
Type = notify
ExecStart = /home/jcherniak/.local/pipx/venvs/maestral/bin/maestral start --foreground --config-name %i
WatchdogSec = 30
ExecStop = /home/jcherniak/.local/pipx/venvs/maestral/bin/maestral stop --config-name %i
ExecStopPost = /usr/bin/env bash -c "if [ ${SERVICE_RESULT} != success ]; then notify-send Maestral 'Daemon failed: ${SERVICE_RESULT}'; fi"
Environment = PYTHONOPTIMIZE=2 LC_CTYPE=UTF-8
User = jcherniak
Group = jcherniak
[Install]
WantedBy=multi-user.target
This works great for the actual syncing. However, when I log in as my user and run maestral status, it says Maestral daemon is not running.
# ps wwaxu | grep maestral
jcherni+ 3330493 16.1 0.2 1463632 89588 ? SNsl 22:05 3:09 /home/jcherniak/.local/pipx/venvs/maestral/bin/python /home/jcherniak/.local/pipx/venvs/maestral/bin/maestral start --foreground --config-name maestral
Given that maestral is running under my username, shouldn't maestral status be able to find it?
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: FalseTHen 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
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)
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.
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 maestral@seb.service: 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
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 sebastien.claude@multiseb.com (Basic)
Usage 40.7% of 5.2 GB used
Status Up to date
Sync errors 0So 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)
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.
Woww !! Thank you so much @samschott it is now working as a charm for me !
If it can help anyone, here is my systemd service definition
[Unit]
Description=maestral service %i
StartLimitIntervalSec=500
StartLimitBurst=5
[Service]
Type=notify
Restart=on-failure
RestartSec=5s
User=seb
Environment=XDG_RUNTIME_DIR=/home/seb/.cache DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus PYTHONOPTIMIZE=2 LC_CTYPE=UTF-8
ExecStart=/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start --foreground --config-name="%i"
ExecStop=/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral stop --config-name %i
[Install]
WantedBy=multi-user.targetThe magic happens clearly with Environment=XDG_RUNTIME_DIR=/home/seb/.cache and as a standard user, I also have to add this env var to get the status. I didn't try to set the Env with the already set XDG_RUNTIME_DIR that points to : /run/user/1000. Maybe this way I won't have to set the env as my user ?
Exemple of commands that work or not for educational purpose
# maestral is running for the 2 accounts and has been lauched by systemd
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ systemctl status maestral@seb.service
● maestral@seb.service - maestral service seb
Loaded: loaded (/etc/systemd/system/maestral@.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2024-07-14 14:11:15 CEST; 12min ago
...
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ ps -ef | grep -v grep | grep maestral
seb 1949927 1 0 14:11 ? 00:00:04 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start --foreground --config-name=seb
seb 1949996 1 0 14:11 ? 00:00:04 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start --foreground --config-name=carole
# Let's try different ways of getting status
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop/ansible$ maestral status -c carole
Maestral daemon is not running.
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop/ansible$ XDG_RUNTIME_DIR=/home/seb/.cache maestral status -c carole
Account caroledropboxphotos@multiseb.com (Basic)
Usage 1.8% of 2.4 GB used
Status Up to date
Sync errors 0
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ sudo su - seb -c "XDG_RUNTIME_DIR=/home/seb/.cache /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c carole"
Account caroledropboxphotos@multiseb.com (Basic)
Usage 1.8% of 2.4 GB used
Status Up to date
Sync errors 0 You can consider to close the issue because all theses explanations should also work for @jcherniak , do you confirm ?
Sorry last update, after a test removing old locks (/home/seb/.cache/maestral dir) and restarting services with an environment like : this Environment=XDG_RUNTIME_DIR=/run/user/1000 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus PYTHONOPTIMIZE=2 LC_CTYPE=UTF-8
It works and of course simplify getting the status as normal user
# maestral is running for the 2 accounts and has been lauched by systemd
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ systemctl status maestral@seb.service
● maestral@seb.service - maestral service seb
Loaded: loaded (/etc/systemd/system/maestral@.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2024-07-14 14:30:25 CEST; 4min 45s ago
...
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ ps -efwww | grep -v grep | grep maestral
seb 1953732 1 0 14:30 ? 00:00:02 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start --foreground --config-name=seb
seb 1953947 1 0 14:30 ? 00:00:01 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start --foreground --config-name=carole
# Let's try different ways of getting status
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop/ansible$ maestral status -c carole
Account caroledropboxphotos@multiseb.com (Basic)
Usage 1.8% of 2.4 GB used
Status Up to date
Sync errors 0
sudo su - seb -c "XDG_RUNTIME_DIR=/run/user/1000 /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c carole"
Account caroledropboxphotos@multiseb.com (Basic)
Usage 1.8% of 2.4 GB used
Status Up to date
Sync errors 0
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ sudo su - seb -c "/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral status -c carole"
Maestral daemon is not running.Not so clear in the end for /run/user/1000 as I have after reboot strange errors and can still see .lock files in .cache/maestral
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ ls -l ../.cache/maestral/
total 96
-rw-rw-r-- 1 seb seb 0 juil. 14 14:33 carole.lock
-rw-r--r-- 1 seb seb 10760 juil. 14 15:06 carole.log
-rw-r--r-- 1 seb seb 0 juil. 14 14:30 seb.lock
-rw-r--r-- 1 seb seb 78606 juil. 14 15:10 seb.log
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ ls -l /run/user/1000/maestral/
total 0
-rw-rw-r-- 1 seb seb 0 juil. 14 14:56 carole.lock
srwxr-xr-x 1 seb seb 0 juil. 14 15:06 carole.sock
-rw-rw-r-- 1 seb seb 0 juil. 14 14:59 seb.lock
srwxr-xr-x 1 seb seb 0 juil. 14 15:06 seb.socksystemd is unable to start the services until I did it manually with : sudo su - seb -c "XDG_RUNTIME_DIR=/run/user/1000 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral stop --config-name=seb"
If I don't specify DBUS_SESSION_BUS_ADDRESS it doesn't work with errors in the log. Oh boy, I wish it owuld have been easier but there are so much things I don't know about the X/Gnome environment it doesn't help
Now after a reboot (and /home/seb/.cach for XDG var) I have an error in the systemd status
(maestral-venv) seb@galaxy-doux:~/ubuntu-desktop$ sudo systemctl status maestral@carole.service
○ maestral@carole.service - maestral service carole
Loaded: loaded (/etc/systemd/system/maestral@.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2024-07-14 15:14:41 CEST; 3min 25s ago
Process: 754 ExecStart=/home/seb/ubuntu-desktop/maestral-venv/bin/python3 -m maestral start --foreground --config-name=carole>
Main PID: 754 (code=exited, status=0/SUCCESS)
Status: "Cannot load keyring keyring.backends.SecretService.Keyring. Please relink Maestral to get a new access token."
CPU: 814msIf I do a systemctl restart maestral@carole.service it works... But if I do nothing manually the service stays inactive (dead)
DO you know where does it come from ?