Description of problem: Package violates: https://fedoraproject.org/wiki/Packaging:DefaultServices#Must_not_require_manual_configuration_to_function As specified in Bug 1608665 grive should require -p option. That means the service cannot run by default without any configuration. Version-Release number of selected component (if applicable): grive2-0.5.0-13.20171122git84c57c1.fc28.x86_64 How reproducible: Always. Steps to Reproduce: # dnf install grive2 $ grive -P -p googledrive/ Actual results: systemd tries to run grive with some wrong (none?) parameters. Expected results: Nothing. Additional info:
*** Bug 1608664 has been marked as a duplicate of this bug. ***
Thanks for the report. I find some serious mistake in the spec file. I will fix this shortly.
After dnf install + dnf remove there are leftover files: lrwxrwxrwx 1 root root 44 Jul 18 10:18 /etc/systemd/user/default.target.wants/grive-changes\@.service -> /usr/lib/systemd/user/grive-changes\@.service lrwxrwxrwx 1 root root 40 Jul 18 10:18 /etc/systemd/user/timers.target.wants/grive-timer\@.timer -> /usr/lib/systemd/user/grive-timer\@.timer with missing targets of the links. There is also leftover empty: drwxr-xr-x 2 root root 4096 Jul 26 16:30 /usr/lib64/grive2/ file /usr/lib64/grive2 is not owned by any package
grive2-0.5.0-13.20171122git84c57c1.fc28.1 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fcde578c75
grive2-0.5.0-13.20171122git84c57c1.fc28.1 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fcde578c75
I am still getting each minute or so: systemd[30084]: grive-changes: Service hold-off time over, scheduling restart. systemd[30084]: grive-changes: Scheduled restart job, restart counter is at 6594. systemd[30084]: Stopped Google drive sync (changed files). systemd[30084]: Started Google drive sync (changed files). systemd[1955297]: grive-changes: Failed to execute command: No such file or directory systemd[1955297]: grive-changes: Failed at step EXEC spawning /usr/lib64/grive2/grive-sync.sh: No such file or directory systemd[30084]: grive-changes: Main process exited, code=exited, status=203/EXEC systemd[30084]: grive-changes: Failed with result 'exit-code'. $ systemctl --user disable grive-changes Failed to disable unit: Unit file grive-changes does not exist. Even if I 'dnf install grive2', then I can run 'systemctl --user disable ...' but then after 'dnf remove grive2' systemd still complains like above.
Emm, this worth to be fixed. However I cannot reproduce it on my machine now.
> Even if I 'dnf install grive2', then I can run 'systemctl --user disable ...' but then after 'dnf remove grive2' systemd still complains like above. From your above sentense, I think you are installing/uninstalling the buggy version (grive2-0.5.0-13.20171122git84c57c1.fc28.x86_64), is this right? The worst problem in that version is, I misconfigured the systemd unit removal logic in that version, so as you said in comment 3, after `dnf remove`, the systemd unit files are still there (but do nothing at all). If this is the case, can you try the following three commands after `dnf remove`? systemctl --user disable grive-changes@.service systemctl --user disable grive-timer@.timer systemctl --user disable grive-timer@.service And check if the files in comment 3 are still existing or not. HTH.
# systemctl --user disable grive-changes@.service Failed to disable unit: Unit file grive-changes@.service does not exist. # systemctl --user disable grive-timer@.timer Failed to disable unit: Unit file grive-timer@.timer does not exist. # systemctl --user disable grive-timer@.service Failed to disable unit: Unit file grive-timer@.service does not exist. (In reply to Zamir SUN from comment #8) > From your above sentense, I think you are installing/uninstalling the buggy > version (grive2-0.5.0-13.20171122git84c57c1.fc28.x86_64), is this right? I was using this command: dnf install https://kojipkgs.fedoraproject.org//packages/grive2/0.5.0/13.20171122git84c57c1.fc28.1/x86_64/grive2-0.5.0-13.20171122git84c57c1.fc28.1.x86_64.rpm > If this is the case, can you try the following three commands after `dnf > remove`? I would expect install+remove of a new package should clean up any mess previous versions of the package made. > systemctl --user disable grive-changes@.service > systemctl --user disable grive-timer@.timer > systemctl --user disable grive-timer@.service # systemctl --user disable grive-changes@.service Failed to disable unit: Unit file grive-changes@.service does not exist. # systemctl --user disable grive-timer@.timer Failed to disable unit: Unit file grive-timer@.timer does not exist. # systemctl --user disable grive-timer@.service Failed to disable unit: Unit file grive-timer@.service does not exist. > And check if the files in comment 3 are still existing or not. They do not. Sure thanks for the update.
grive2-0.5.0-13.20171122git84c57c1.fc28.1 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
I still have the same problem following the latest update (I uninstalled and then installed the package): [user1@PC ~]$ rpm -q grive2 grive2-0.5.0-13.20171122git84c57c1.fc28.1.x86_64 Aug 06 18:47:13 PC systemd[1293]: grive-changes: Service hold-off time over, scheduling restart. Aug 06 18:47:13 PC systemd[1293]: grive-changes: Scheduled restart job, restart counter is at 1009. Aug 06 18:47:13 PC grive-sync.sh[25458]: Need a directory name in the current users home directory as second argument. Aborting. Aug 06 18:47:13 PC systemd[1293]: grive-changes: Main process exited, code=exited, status=1/FAILURE Aug 06 18:47:13 PC systemd[1293]: grive-changes: Failed with result 'exit-code'. [user1@PC ~]$ systemctl --user list-unit-files | grep grive grive-changes@.service disabled grive-timer@.service static grive-timer@.timer disabled [user1@PC ~]$ systemctl --user disable grive-changes@.service [user1@PC ~]$ systemctl --user disable grive-timer@.service [user1@PC ~]$ systemctl --user disable grive-timer@.timer [user1@PC ~]$ systemctl --user list-unit-files | grep grive grive-changes@.service disabled grive-timer@.service static grive-timer@.timer disabled The only way I can stop the constant logging is to manually remove the following files and reload the systemd daemon: [user1@PC ~]# rpm -ql grive2 | grep systemd /usr/lib/systemd/user/grive-changes@.service /usr/lib/systemd/user/grive-timer@.service /usr/lib/systemd/user/grive-timer@.timer
Thanks Tibbs. I cannot reproduce the exact scenario you said, but I think I figured out the manual action to solve the issue fully. The root cause is the serious misuse of macro in the SPEC file. The essential fix to this bug remains unchanged. But the manual steps that are needed to fully address this changed a bit. To all people who had met this bug, sorry about this. The best way to totally fix this is following. For people who want to remove grive2 fully, following this steps 1. # dnf remove grive2 2.1 # systemctl --user disable grive-changes@.service 2.2 # systemctl --user disable grive-timer@.service 2.3 # systemctl --user disable grive-timer@.timer 2.4 # systemctl --global disable grive-timer@.timer 2.5 # systemctl --global disable grive-changes@.service 2.6 # systemctl daemon-reload This will solve no matter which way these services are installed/enabled. For people who want to still use grive2, but do not want to see these annoying messages. 1. # dnf update grive2 2. Repeat step 2.1 to step 2.6 that is shown above For people who have never installed anything older than the following versions, you won't see this bug at all. Fedora 28 grive2-0.5.0-13.20171122git84c57c1.fc28.1 Fedora 29 grive2-0.5.0-15.20171122git84c57c1.fc29 EPEL 7 grive2-0.5.0-2.20171122git84c57c1.el7.1
Thanks for your effort but after: # dnf remove grive2 No match for argument: grive2 Error: No packages marked for removal. # systemctl --user disable grive-changes@.service Failed to disable unit: Unit file grive-changes@.service does not exist. # systemctl --user disable grive-timer@.service Failed to disable unit: Unit file grive-timer@.service does not exist. # systemctl --user disable grive-timer@.timer Failed to disable unit: Unit file grive-timer@.timer does not exist. # systemctl --global disable grive-timer@.timer Failed to disable unit, unit grive-timer@.timer does not exist. # systemctl --global disable grive-changes@.service Failed to disable unit, unit grive-changes@.service does not exist. # systemctl daemon-reload # _ I still get the messages: systemd[1655167]: grive-changes: Failed to execute command: No such file or directory systemd[1655167]: grive-changes: Failed at step EXEC spawning /usr/lib64/grive2/grive-sync.sh: No such file or directory systemd[30084]: grive-changes: Main process exited, code=exited, status=203/EXEC systemd[30084]: grive-changes: Failed with result 'exit-code'. systemd[31525]: grive-changes: Service hold-off time over, scheduling restart. systemd[31525]: grive-changes: Scheduled restart job, restart counter is at 96942. systemd[31525]: Stopped Google drive sync (changed files). systemd[31525]: Started Google drive sync (changed files). systemd[1655170]: grive-changes: Failed to execute command: No such file or directory systemd[1655170]: grive-changes: Failed at step EXEC spawning /usr/lib64/grive2/grive-sync.sh: No such file or directory systemd[31525]: grive-changes: Main process exited, code=exited, status=203/EXEC systemd[31525]: grive-changes: Failed with result 'exit-code'.
Did you execute the following three with normal users (the user that you've tried `grive -P -p....`), or under root? # systemctl --user disable grive-changes@.service # systemctl --user disable grive-timer@.service # systemctl --user disable grive-timer@.timer For me I am using root in my testing environment, so I am using root. The worst case you can try remove the following files manually, as Tibbs commented in comment 11. /usr/lib/systemd/user/grive-changes@.service /usr/lib/systemd/user/grive-timer@.service /usr/lib/systemd/user/grive-timer@.timer ... and do a 'systemctl daemon-reload' after all above removed.
And if removing the files and do a daemon-reload still cannot help, please still follow up on this bug, I might need your help for reproducing what's actually happening on your environment.
(In reply to Zamir SUN from comment #14) > Did you execute the following three with normal users (the user that you've > tried `grive -P -p....`), or under root? > > # systemctl --user disable grive-changes@.service > # systemctl --user disable grive-timer@.service > # systemctl --user disable grive-timer@.timer I ran it above as a root. If I run it as a user which was using grive I get: $ systemctl --user disable grive-changes@.service Failed to disable unit: Unit file grive-changes@.service does not exist. $ systemctl --user disable grive-timer@.service Failed to disable unit: Unit file grive-timer@.service does not exist. $ systemctl --user disable grive-timer@.timer Failed to disable unit: Unit file grive-timer@.timer does not exist. > The worst case you can try remove the following files manually, as Tibbs > commented in comment 11. Nothing there: # find /usr/lib/systemd/ -iname "*grive*" # find /etc/systemd/ -iname "*grive*" # _ In fact nothing "*grive*" anywhere: # locate grive -> -rw------- 1 lace lace 65 Jul 17 13:40 /home/lace/.grive -rw------- 1 lace lace 65 Jul 18 13:56 /home/lace/googledrive/.grive -rw-r--r-- 1 lace lace 2887 Jul 18 13:56 /home/lace/googledrive/.grive_state > ... and do a 'systemctl daemon-reload' after all above removed. I could not remove anything. And I already did 'systemctl daemon-reload' in Comment 13. I believe it is systemd's fault. :-)
Having uninstalled the package on my server, running any of the "systemctl --user" commands as root simply threw the following message because there was no "systemd --user" process running: Failed to connect to bus: No such file or directory From the journal I could see that the messages were coming from a process running under the "gdm" user: Aug 28 15:51:55 PC systemd[2077]: grive-changes: Service hold-off time over, scheduling restart. Aug 28 15:51:55 PC systemd[2077]: grive-changes: Scheduled restart job, restart counter is at 5127. Aug 28 15:51:55 PC systemd[16165]: grive-changes: Failed to execute command: No such file or directory Aug 28 15:51:55 PC systemd[16165]: grive-changes: Failed at step EXEC spawning /usr/lib64/grive2/grive-sync.sh: No such file or directory Aug 28 15:51:55 PC systemd[2077]: grive-changes: Main process exited, code=exited, status=203/EXEC Aug 28 15:51:55 PC systemd[2077]: grive-changes: Failed with result 'exit-code'. UID PID PPID C STIME TTY TIME CMD gdm 2077 1 0 Aug26 ? 00:00:15 /usr/lib/systemd/systemd --user So I switched to that user: su -s /usr/bin/bash - gdm Exported the following variable: export XDG_RUNTIME_DIR="/run/user/$UID" And then reloaded the systemd daemon: systemctl --user daemon-reload At this point the messages were no longer being logged. I can confirm that the messages are no longer logged after re-installing the latest version of the package.
I do not have any gdm here (XFCE system, I have lightdm) but that was not related to it. I have found from the systemd PIDs in those error messages they come from: root 30084 0.0 0.0 88296 5164 ? Ss Jul25 3:54 /usr/lib/systemd/systemd --user jkratoch 31525 0.0 0.0 88292 5360 ? Ss Jul25 3:11 /usr/lib/systemd/systemd --user And it is fixed now, one needs to do: systemctl --user daemon-reload as those two users, even as the root. As just systemctl daemon-reload as root is not enough. I am not sure how that can be automated from the rpm scripts, maybe it could.