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
