Improvement to systemd unit

[guyest]

• Your vdirsyncer version
  0.16.7
• If applicable, which server software (and which version) you're using
  n/a
• Your Python version
  3.7
• Your operating system
  arch linux
• Your config file
  n/a
• Use vdirsyncer -vdebug for debug output. The output is sensitive, but
  please attach at least the last few lines before the error (if applicable),
  censored as necessary. This is almost always the most useful information.
  n/a

---

No error here. Just wanted to open a ticket to raise the possibility of a couple potential improvements to the systemd unit files that are shipped by default. Of course these can be edited by the user as suggested in the documentation, but sane defaults are always nice.

In the unit section of vdirsyncer.service:
After = network.target network-online.target dbus.socket
That way, there is no problem with trying to reach a remote resource if the machine takes longer than the default of 5min to obtain network connectivity. This is what is done by similar syncing services likes mbsync or fdm.

In the service section of vdirsyncer.service:
ExecStartPre = /usr/bin/vdirsyncer discover
That way, when a new dav resource is created it does not have to be added manually. This one is a bit trickier and possibly not a good default. There would need to be a way to pass the prompt from discover and allow it to make the new collections.

[WhyNotHugo]

Adding After = network.target network-online.target dbus.socket makes sense to me.

Not sure about ExecStartPre, since this might trigger interactive questions.

[dvzrv]

Not sure about ExecStartPre, since this might trigger interactive questions.

How so? Do you mean as in "type in your password" or similar?

[guyest]

Well I think what @WhyNotHugo was getting at is what I implicitly suggested was a difficulty: if discover finds new items, how does it decide what to do? Does the user always want every new collection to be downloaded? What if there is a conflict? How is this managed in the background? There would have to be a way to alert the user of what is happening in this situations, making it probably not a great bet as a default --- at least not without some additional settings in the config file that allow specification of how to deal with these edge cases.

[matt-snider]

I'm currently doing exactly what you suggested in a systemd unit. As commented in #425, although there is no non-interactive mode currently you can do yes | vdirsyncer discover. @guygma does raise a good point - the user may not want every new collection to be downloaded.

I haven't found a way to start a program for conflict resolution from systemd. I'd like to do something like conflict_resolution = [ "command", "nvim", "-d" ], but of course this doesn't work from the systemd unit. Any ideas how to get something like this working?

[WhyNotHugo]

Wow, this is old. Let me clarify:

Not sure about ExecStartPre, since this might trigger interactive questions.

This might trigger questions like "collection X not found locally, do you want to create it?". Since it's not running interactively, it'll just fail and exit. Discovery needs to be done manually as long as it requires user intervention.

I haven't found a way to start a program for conflict resolution from systemd. I'd like to do something like conflict_resolution = [ "command", "nvim", "-d" ], but of course this doesn't work from the systemd unit. Any ideas how to get something like this working?

Sounds very far from being doable. This is running in the background. Where do we show nvim? Is the user running just a VT? Xorg? Wayland? What's their terminal emulator? What if they're watching a movie, do we still want to pop up a windows with vim?

I do agree that we want to inform the user of conflict. The question I can't seem to find an answer for is: how?

Maybe a separate timer that sends you an email if any user timer failed? If that's the best solution, it's best left as a separate package, and not a vdirsyncer feature. I'm open to other ideas though.

After = network.target network-online.target dbus.socket

Sadly, user-units can't rely on system-units, so this dependency order cannot be specified. Systemd limitation. Can't do much around it. 🤷‍♂️

I don't think there's anything actionable here (in other words: I'm out of ideas here).

[WhyNotHugo]

#869 should be enough to handle auto-creation of new collections.

As for the other points here, there's nothing to be done.