Hi Simon,
thanks again!!
> I still think doing this as a user service (like pulseaudio, gpg-agent,
> dbus-daemon --session, rygel, flatpak-session-helper, tracker-store, etc.)
> would be a better approach to use by default: that sort of thing is exactly
> what `systemd --user` is designed for.
But isn't that what we are doing by shipping
/usr/lib/systemd/user/onedrive.service
?
Am I missing something here?
> Or perhaps it would make sense to have both implementations, like you said
> you've done, but swap round their enabledness: enable the user service by
> default, but provide example system units (disabled by default) that can
> be used by sysadmins who consider the advantages of running this as a
> system service to outweigh the disadvantages?
We don't enable **anything** by default since it requires interaction by
the user (log into the onedrive account, provide response URL).
That is also the reason why I don't see any use for a system service.
> I assume this package is a FUSE filesystem (or some other daemon) for access
> to Microsoft OneDrive? It might be useful to compare it with other
No, it is a user space program that syncs a directory with the content
in the OneDrive cloud, more similar to the dropbox client or insync
client. It can run in one-shot sync mode, as well as monitor mode using
notify events.
> It looks as though the system service would have to be enabled manually
> on a per-user basis *anyway*, because the package can't know which users
> it is meant to be enabled for; so perhaps the best way would be something
> like this in README.Debian, and arranging the packaging so that it becomes
> true:
[...]
As I said, I think nothing should be automatically enabled from the
system side (equivalent of systemctl --user --global disable
onedrive.service), so the only information necessary would be
Users can enable the service for themselves by running the command:
$ systemctl --user enable onedrive.service
All the rest for sysadm enabling for all will simply not work due to the
requirement of initial interactive setup.
> > /lib/systemd/system/onedrive@.service
> > --------------------------------------
> ...
> > After=network-online.target
> > Wants=network-online.target
> > PartOf=onedrive.target
> >
> > [Service]
> > ExecStart=/usr/bin/onedrive --monitor --confdir=/home/%i/.config/onedrive
>
> If you are sure you want this to be a system service, this looks
> right. However, as you said, this assumes every user's home directory
> is /home/${LOGNAME}. It also won't respect the user's ${XDG_CONFIG_HOME}
> (it assumes the default ~/.config).
>
> systemd documents that it sets ${HOME} for system services that
> have User= (at least in recent-ish versions, I'm not sure how
Ahh, that is a good info. It wasn't like this back when I wrote the
current version of unit files.
Upstream will probably not change that, since we (upstream) support also
older RH/Fedora etc, where ${HOME} might not be available, but for the
Debian packages I can use ${HOME}. Thanks.
> users set PATH, XDG_CACHE_HOME, XDG_CONFIG_HOME or LANGUAGE, nothing
> that onedrive does will respect those environment variables.
Besides --confdir, onedrive doesn't care for any of these variables in
any way at the moment.
> If onedrive wants to access the D-Bus session bus, for example to send
It does when started as user service, by connecting to the notification
system and sending notifications.
> /lib/systemd/system/onedrive.target. If you *don't* give the target
> an [Install] section:
>
> # /lib/systemd/system/onedrive.target
> [Unit]
> Description=OneDrive clients
> Documentation=...
> # end of file
>
> but instead give onedrive@.service a Wants on it:
>
> # /lib/systemd/system/onedrive@.service
> [Unit]
> ...
> After=network-online.target
> Wants=network-online.target onedrive.target
>
> then it will automatically become part of system boot if and only if
> at least one instance of onedrive@.service is enabled, which I think is
> probably the right thing to do.
Ahh, that is a good idea. That would keep things a bit cleaner.
> > /usr/lib/systemd/user/onedrive.service
> > --------------------------------------
> ...
> > After=network-online.target
> > Wants=network-online.target
> > PartOf=onedrive.target
>
> These will not have any effect (unless you have created a
Ok, so better to be removed, just useless.
> service managers, with entirely separate ecosystems of units: neither
> can see units that were configured for the other.
Ok, that will leave user-unit based onedrive process running until the
user logs out.
And then, again, this might be a problem if combined with lingering etc
etc.
Bottomline for me is that it seems there is no reliable way to restart
user services (services started via systemctl --user) besides waiting
for reboot. And this again could make some postinstall script code
interesting...
Looking at the insync postinst code (which does that for logged in
users), hmmm, I am a bit in doubt though:
insync_process="\\./insync start|/usr/lib/insync/insync"
pids=$(pgrep -f "$insync_process" || :)
if ! [ -z "$pids" ]; then
uids=$(ps -o uid= -p $pids | uniq)
for x in $(echo $uids); do
insync_sock="/tmp/insync$x.sock"
if [ -e $insync_sock ]; then
user=$(stat -c '%U' $insync_sock)
su - $user -c "insync quit"
sleep 5s
fi
sec=$(pgrep -f "$insync_process" -U $x || :)
if [ -z "$sec" ]; then
continue
fi
pkill -f "$insync_process" -U $x
sleep 5s
lst=$(pgrep -f "$insync_process" -U $x || :)
if [ -z "$lst" ]; then
rm $insync_sock || true
continue
fi
pkill -KILL -f "$insync_process" -U $x
rm $insync_sock || true
done
fi
Thanks for all your insightful comments, that helps a lot!!!
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
