Can't find sync services status with systemctl

[majneb]

My google-drive folder is located in ~/google-drive. For now I use to sync it manually with the grive command in this folder and it works. But I am not sure how to properly set the partial auto sync feature : after installing inotify-tools, I enter the following command as written in the readme.md file :

systemctl --user enable grive@$(systemd-escape google-drive).service
systemctl --user start grive@$(systemd-escape google-drive).service

which returns the following :

Created symlink /home/majneb/.config/systemd/user/default.target.wants/grive@google\x2ddrive.service → /usr/lib/systemd/user/grive@.service.

But this does not seem to work : when I try to modify a simple text file in the local google-drive folder, it is not synced to the remote. So I try to check the systemctl status of the service, and I could not find it : systemctl status grive@$(systemd-escape google-drive).service returns Unit grive@google\x2ddrive.service could not be found., and systemctl status grive@ returns Failed to get properties: Unit name grive@.service is neither a valid invocation ID nor unit name.

I also tried to manually activate changes and timer sync with

systemctl --user enable grive-timer@$(systemd-escape google-drive).timer
systemctl --user start grive-timer@$(systemd-escape google-drive).timer
systemctl --user enable grive-changes@$(systemd-escape google-drive).service
systemctl --user start grive-changes@$(systemd-escape google-drive).service

but I add the same result.

I am quite sure I am wrong somewhere. How should I get it to work ?

By the way thank you for this amazing tool !

[jankatins]

I usually use something like journalctl | grep grive to see if my grive runs.

The above will probably not work because the grive@.service unit is only used to depend on two other units: grive-timer@.service (and the corresponding .timer) and grive-changes@.service. Might be worth to check these two for any status.

[majneb]

Hi @jankatins, thank you for your answer. I tried journalctl | grep grive and it seems that grive is running as I have lot of events of it since yesterday. Most of the time, the message which is returned is something like grive-sync.sh[8748]: Retriggered google drive sync ('google-drive'), and sometimes the sync happen : grive-sync.sh[2449]: Syncing 'google-drive'....

I tested another time to modify a simple text file in my local grive folder, and I checked in journalctl a few times in the 20 minutes following the change : I only got few grive-sync.sh[xxxx]: Retriggered google drive sync ('google-drive') just after I modify the file, but then nothing more. In the remote, the file is still not updated.

I also tried systemctl status grive-timer@.service and systemctl status grive-changes@.service but it also returns Failed to get properties: Unit name grive@.service is neither a valid invocation ID nor unit name.

[jankatins]

Re status: they need the escaped path behind the @, sumilar to the enable for the main unit

I assumed that you restarted grive inbetween: can it be that it is stuck somewhere? E.g check with htop if there is a grive binary running or and since when. I sometimes have it stuck and then it doesn't do anything until i restart it. Eg via "killall grive" (which let systemd restart the service).

[majneb]

Re status: they need the escaped path behind the @, sumilar to the enable for the main unit

I did this also with the command systemctl status grive-changes@$(systemd-escape google-drive).service and I get the same message : Unit grive-changes@google\x2ddrive.service could not be found., same for grive-timer.

But the killall works for me ! Sync works in the 2 directions, from remote to local and from local to remote.

I think for me the issue can be closed, I still can't find status with systemctl, but a workarround is to use journalctl to get informations, and debug with the killall grive command.

[jankatins]

It seems it would be good to add a timeout to the grive script systemd unit itself, so this will be resolved automatically.

but why it gets stuck is actually also a bug which seems to exist.

[pyro12]

@jankatins

but why it gets stuck is actually also a bug which seems to exist

Most of this thread is over my head, but anecdotally I've noticed that updating my system (I'm using Debian Stable so an apt upgrade) can sometimes cause grive to freeze. I don't have any logs or anything. I don't know if it happens when a dependency is updated or if it happens when grive tries to run mid-upgrade... or what.

I thought this information might be helpful for anyone trying to track down why grive freezes so I'm dropping it here.

I usually just restart my system. Annoying but simple solution.

[eldar]

I can confirm the bug. I change files locally, the log is full of messages like this:

grive-sync.sh[143885]: Retriggered google drive sync ('data/GoogleDrive')

But no sync is happening. killall grive seems to get it out of this state.

[pyro12]

#!/bin/bash
sleep 2m
cd ~/grive
while true
do
grive &
sleep 30m
killall grive
done

Definitely a workaround, but I have this simple script as a hidden file in my grive directory and set to run at startup. Waits two minutes, assumes that's enough time for network to be fully up, starts a sync grive, wait 30min, kill grive (in case it is hanging), loop.

No fancy, not a service, no daemons, 'wonky', bad practice to us CD in a script, etc, but it's been keeping grive on both my PC's synced for over a week now with no issues.

[Guangyun-Xu]

@pyro12 good idea! but I want to know how did you get this script to automatically run on boot?

[pyro12]

@Guangyun-Xu

There are a number of ways to do that. Most depend on which Desktop Environment you've chosen. I'm using Plasma and it has an 'autostart' tab in settings where you simply direct it to the script you wish to start on boot. iirc, XFCE has a similar setting. I would be surprised if GNOME didn't have one as well.

Never done it, but I'm pretty sure you could make it a CRON job, as well.

for any of these to work, you of course have to chmod +x [filename] once after saving the script.

[jankatins]

389 runs grive with a timeout of 20min so in theory a stuck grive should not lead to (too much) lost data in case you rely on syncing it out as a backup solution... The number was chosen because I hope that noone would ever upload a file big enough to take 20+min...