Make a systemd user service go away?

[Tom Horsley]

I installed the grive2 package so I could manually,
when I need to upload a file to google drive via
a command line tool. It works (clumsily) for this.

But the package also installs a bunch of systemd user
services and timers that unsuccessfully try to
sync some nonexistant directory every half hour,
filling the log with fantastic numbers of errors.

I tried to do systemctl disable --user commands
on these things to make them go away, but it
had no effect.

I did a "find" to discover all the places cluttered
with these grive units and came up with this big
hammer to eradicate them:

rm -rf /usr/lib/systemd/user/grive-changes@.service \
   /usr/lib/systemd/user/grive-timer@.service \
   /usr/lib/systemd/user/grive-timer@.timer \
   /etc/systemd/user/timers.target.wants/grive-timer@.timer \
   /etc/systemd/user/default.target.wants/grive-changes@.service

But even after doing that the damn log messages keep
appearing as though systemd has them squirrelled away
somewhere and refuses to relinquish them. (I'll soon
learn if rebooting after that manages to work).

So I have to ask, is there some "official" way to make
systemd user services go away and stop bothering me?

[Greg Woods]

On Fri, May 11, 2018 at 5:55 AM, Tom Horsley <horsley1953(a)gmail.com&gt; wrote:

>  So I have to ask, is there some "official" way to make
>  systemd user services go away and stop bothering me?
>  
# systemctl stop <servicename>
# systemctl mask <servicename>

Unfortunately, "disable" only removes the service from the
auto-start-at-boot list, it doesn't prevent some other application from
starting it. To be SURE a service cannot be started, mask it.

--Greg

[Tom Horsley]

On Fri, 11 May 2018 06:30:37 -0600
Greg Woods wrote:

>  On Fri, May 11, 2018 at 5:55 AM, Tom Horsley
> <horsley1953(a)gmail.com&gt; wrote:
>  
>  >
>  >
>  > So I have to ask, is there some "official" way to make
>  > systemd user services go away and stop bothering me?
>  >  
>  
>  # systemctl stop <servicename>
>  # systemctl mask <servicename>
>  
>  Unfortunately, "disable" only removes the service from the
>  auto-start-at-boot list, it doesn't prevent some other application from
>  starting it. To be SURE a service cannot be started, mask it. 
That works great for "normal" services, but these are "user"
services. I've tried adding the --user option but the normal
disable/mask/stop stuff doesn't appear to have any effect at all
on these "user" services even with the --user option.

Though I think rebooting after removing the files has finally
worked. It has been an hour or so and no new log messages
have appeared :-).

[Patrick O'Callaghan]

On Fri, 2018-05-11 at 07:55 -0400, Tom Horsley wrote:
>  I installed the grive2 package so I could manually,
>  when I need to upload a file to google drive via
>  a command line tool. It works (clumsily) for this.
>  
>  [...] 
>  So I have to ask, is there some "official" way to make
>  systemd user services go away and stop bothering me? 
Not a direct answer to your question, but I've found
rclone (https://rclone.org/) to work pretty well.
It has backends for a lot of cloud providers, not just Google.

poc

[Tom H]

On Fri, May 11, 2018 at 7:55 AM, Tom Horsley <horsley1953(a)gmail.com&gt; wrote:
>  I installed the grive2 package so I could manually,
>  when I need to upload a file to google drive via
>  a command line tool. It works (clumsily) for this.
>
>  But the package also installs a bunch of systemd user
>  services and timers that unsuccessfully try to
>  sync some nonexistant directory every half hour,
>  filling the log with fantastic numbers of errors.
>
>  I tried to do systemctl disable --user commands
>  on these things to make them go away, but it
>  had no effect.
>
>  I did a "find" to discover all the places cluttered
>  with these grive units and came up with this big
>  hammer to eradicate them:
>
>  rm -rf /usr/lib/systemd/user/grive-changes@.service \
>     /usr/lib/systemd/user/grive-timer@.service \
>     /usr/lib/systemd/user/grive-timer@.timer \
>     /etc/systemd/user/timers.target.wants/grive-timer@.timer \
>     /etc/systemd/user/default.target.wants/grive-changes@.service
>
>  But even after doing that the damn log messages keep
>  appearing as though systemd has them squirrelled away
>  somewhere and refuses to relinquish them. (I'll soon
>  learn if rebooting after that manages to work).
>
>  So I have to ask, is there some "official" way to make
>  systemd user services go away and stop bothering me? 
Were some user services installed in $HOME?

Do they show up with "systemctl --user"?

[Tom Horsley]

On Fri, 11 May 2018 08:36:09 -0400
Tom H wrote:

>  Were some user services installed in $HOME? 
There wasn't anything in $HOME with the name '*grive*'
in it that find could find. Just the entries installed
by the package in /usr/lib/systemd/user

>  Do they show up with "systemctl --user"? 
They did indeed show up with the --user option,
but the --user option didn't seem to have any ability
to make them stop or disabled or any other kind
of manipulation.

Anyway, with my "big hammer" of removing all the
files then rebooting, it seems to have stopped.

Without rebooting it kept going even with the files
removed, so that's what I was wondering about. Is
there anything less drastic than rebooting to
convince systemd they are gone?

[Ahmad Samir]

On 11 May 2018 at 14:49, Tom Horsley <horsley1953(a)gmail.com&gt; wrote:
[...]
>  Without rebooting it kept going even with the files
>  removed, so that's what I was wondering about. Is
>  there anything less drastic than rebooting to
>  convince systemd they are gone?
>  
# systemctl daemon-reload

-- 
Ahmad Samir

[Tom Horsley]

On Fri, 11 May 2018 15:03:24 +0200
Ahmad Samir wrote:

>  # systemctl daemon-reload 
I always forget that exists. I'll try it if grive2 ever
gets an update and re-installs the files. Thanks.

[Ahmad Samir]

On 11 May 2018 at 14:49, Tom Horsley <horsley1953(a)gmail.com&gt; wrote:
>  On Fri, 11 May 2018 08:36:09 -0400
>  Tom H wrote:
>
> > Were some user services installed in $HOME?
>
>  There wasn't anything in $HOME with the name '*grive*'
>  in it that find could find. Just the entries installed
>  by the package in /usr/lib/systemd/user
>
> > Do they show up with "systemctl --user"?
>
>  They did indeed show up with the --user option,
>  but the --user option didn't seem to have any ability
>  to make them stop or disabled or any other kind
>  of manipulation.
>
>  Anyway, with my "big hammer" of removing all the
>  files then rebooting, it seems to have stopped.
>
>  Without rebooting it kept going even with the files
>  removed, so that's what I was wondering about. Is
>  there anything less drastic than rebooting to
>  convince systemd they are gone? 
IIRC, this worked for me before, though it was a long time ago and the
details are a bit hazy in my mind:
- Create ~/.local/share/systemd/user/
- Put a symlink, with the name of the offending systemd "user" service
to /dev/null; technically this is like masking a regular systemd
service.

-- 
Ahmad Samir