systemd: using systemd.service parametrization to point to custom configuration

[d4gg4d]

Hi,

I was following these instructions to setup multiple account and come up to think that should [email protected] be parameterized differently? If we would bind the configuration directory instead of user home dir, we could easily enable multiple accounts. For example if it would would be like this,

[Unit]
...
Description=OneDrive Free Client for %i account

[Service]
...
ExecStart=@prefix@/bin/onedrive --monitor --confdir=%h/.config/onedrive-%i
...

[Install]
WantedBy=default.target

Then by creating config to folder ~/.config/onedrive-foobar, one could spin up a new syncing service to account foobar by running

systemctl enable --user onedrive@foobar

I can create PR if it is considered a worthy of doing.

ps. during the pondering, I haven't considered running this as system service (i.e. root), only as an user specific service.

[abraunegg]

@d4gg4d

ExecStart=@prefix@/bin/onedrive --monitor --confdir=%h/.config/onedrive-%i
...
I can create PR if it is considered a worthy of doing.

What has been documented has been tested and validated & works correctly. In terms of a PR:

• How would these suggested changes work in a non-multi configuration?
• What would happen to existing deployed consumers of the existing service file (given their running copies are symbolically linked to this file) ... ?

Some extreme testing and validation of all scenarios would be needed here - not just a PR changing a single line of code. All documentation would need to be updated as well.

Additionally, the merge window for v2.4.22 is closing, and post closure that will be the last release for v2.4 series. No bugs or issues will be fixed for v2.4 series unless it is an absolute show stopper.

[d4gg4d]

I thought this a little bit and doing modification to existing .service files probably is not worth of an effort. Maybe one could consider separately named service file for multi-account cases, then the existing usage wouldn't be interfered with this addition. Optimal outcome would be somewhat simpler guidance to follow in cases where one needs/wants to have multiple onedrive accounts for the same user.

My personal need for the multi-account actually got down prioritized, as I found out that the other account I was suppose to be using, can't be synced due to MDM policies in the server. But when I have energy, I could create that PR for review (new service file and documentation changes). Do I think correctly, that if we would introduce new service file, the testing requirements wouldn't be so extensive in that case?