Hi Simon,

> Yes it is, but you started this thread by asking for advice about how
> to restart an instanced *system* service on upgrade, which gave me the
> impression that you consider the system service to be what you recommend
> to users as the most normal way to run this onedrive service.

Well, I don't have a strong feeling about this. I guess because *I* use
the instanced *system* service I somehow tend to prefer it. I don't need
the notifications, but I want to sync stuff even when I am not logged
in.

> If I'm understanding correctly, each user who wants to run this service
> in monitor mode needs to either:
> - enable it as a systemd user service (using the unit in
>   /usr/lib/systemd/user)
> or
> - (ask their sysadmin to) enable it as an instanced system service with
>   instance name = their username (using the unit in /lib/systemd/system),
> or
> - run it in some way that doesn't involve systemd

Yes, exactly.

> but they need to choose exactly one of those ways, and it is pointless
> to have more than one for the same user. Is that right?

Yes, absolutely. In fact, running two instances via different methods
will crash one ;-)

> If I'm correct to think that, then I would say that you should
> recommend the user-service as the most-preferred way, with the others
> as alternatives for people with unusual needs.

Ok, thanks. I will adjust the documentation accordingly.

> > That is also the reason why I don't see any use for a system service.
> 
> Now I'm confused. You started this thread asking for advice about how to

Sorry for the confusion, I thought about a non-instanced system service
(/lib/systemd/system/onedrive.service). We don't ship it, and I don't
think it makes sense to ship it.

The *instanced* system service OTOH is something I would keep (at least
for me ;-)

> Is what you mean here: a user-service is a viable route to use this
> program; and an instanced system service that is run per user and
> behaves as though it wants to be a user-service is also viable; but you
> see no use for a system service that is genuinely running on behalf of
> the entire multi-user system, similar to atd.service or cups.service
> or rsyslog.service?

Yes. That explains is correclty.

> OK, that makes sense. You should be able to achieve this with:
> 
>     dh_installsystemduser --no-enable

Hmm, I have
override_dh_installinit:
        dh_installinit --no-start --no-enable

but the actual .service files are already installed by upstream's make
install.

Is there a considerable difference?

> A few packages use killall or pkill to tell user services to restart or
> reload, but that isn't exactly robust: it relies on rummaging through

Agreed (and I don't like it).

> Honestly, the more experience I get in distro development, the more
> convinced I am that "reboot to update" is the robust thing to do for

Agreed on that.

> >       su - $user -c "insync quit"
> 
> Defnitely please don't do this. Having system-level code reach into

I don't do it, that is too crazy a code for me to see in postinst. But
it is what is shipped in insync (not in Debian!).

All the best

Norbert

--
PREINING Norbert                              https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Reply via email to