Include a simple systemd service with the client

[ngoonee]

Expected behaviour

A nextcloud-client.service (or [email protected]) should be available for linux users/packagers.

Actual behaviour

Currently not available, some distros just roll their own.

Additional information

One of the most common systemd service units looks something like this:-

[Unit]
Description=Nextcloud Client

[Service]
Type=simple
ExecStart=/usr/bin/nextcloud
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=default.target

A system-wide service unit would be a bit more complex as DBUS_SESSION_BUS_ADDRESS and DISPLAY would need to be set there, but that would also be helpful as a base point for packagers.

[tuxmaster5000]

As far I know, gnome will start it automatic, when select in the client.
So why do you need an systemd unit?

[ngoonee]

Because:-

1. Not everyone uses gnome
2. systemd units can depend on other units (e.g. can be set to depend on networking being up, thus it would stop when networking is down)
3. systemd allows for chaining/modification of units (so specific proxies for a machine can be set in a systemd service drop-in)

[myroad94]

Systemd service are global, not per user. However, Nextcloud client desktop is per user. So what you ask is incompatible. You cannot ask Nextcloud installer, that installs at system level, a user specific start script.
But in your case, your systemd unit would depend on the desktop service to be started (ex kde). Then you would need to export the correct DISPLAY environment variable for the client to start in the correct. But this is very hackish and I do not see the point. As tuxmaster said, nextcloud desktop client is automatically started when the favorite desktop (kde gnome) starts.

[ngoonee]

You can provide a [email protected] file which can be enabled per-user (and runs as that user)

[myroad94]

You can provide a [email protected] file which can be enabled per-user (and runs as that user)

Let's say we install nextcloud client in a machine of 3 users, in CentOs. We do yum install, then the systemd file is deployed. Which user should we choose? Then in case of user removal?

Instead, this is the role of the Desktop Manager (Kde Gnome etc) to start applications at user login.

[ngoonee]

You can provide a [email protected] file which can be enabled per-user (and runs as that user)

Let's say we install nextcloud client in a machine of 3 users, in CentOs. We do yum install, then the systemd file is deployed. Which user should we choose? Then in case of user removal?

Instead, this is the role of the Desktop Manager (Kde Gnome etc) to start applications at user login.

The systemd unit file is not deployed, it is merely provided.

Any user who wants the nextcloud client enabled/started can just run:-

systemctl enable --now nextcloud-client@myusername

This works on all sorts of systems, whether they use DEs or not, and it does not affect anyone who wishes to use DE autostart since it's opt-in. Perfectly compatible with multi-user systems.

[aGolduck]

In my experience, nextcloud client on Linux is not stable enough. It breaks every two to three days. This is very awkward for me because I often connect to my linux using ssh from a remote machine. I can't start it again manually. Systemd can keep it running in the background.

[myroad94]

In my experience, nextcloud client on Linux is not stable enough. It breaks every two to three days. This is very awkward for me because I often connect to my linux using ssh from a remote machine. I can't start it again manually. Systemd can keep it running in the background.

Hi, for that specific need, you can avoid Nextcloud UI by just using nextcloud-client (https://docs.nextcloud.com/desktop/2.6/advancedusage.html#nextcloud-command-line-client). It is less user-friendly because you don't have an UI but this is usable in command-line. You would need to do a cron in this case. Or just use Docker image (like https://hub.docker.com/r/zzenld/nextcloud-client ) if you are familiar with Docker.

[aGolduck]

In my experience, nextcloud client on Linux is not stable enough. It breaks every two to three days. This is very awkward for me because I often connect to my linux using ssh from a remote machine. I can't start it again manually. Systemd can keep it running in the background.

Hi, for that specific need, you can avoid Nextcloud UI by just using nextcloud-client (https://docs.nextcloud.com/desktop/2.6/advancedusage.html#nextcloud-command-line-client). It is less user-friendly because you don't have an UI but this is usable in command-line. You would need to do a cron in this case. Or just use Docker image (like https://hub.docker.com/r/zzenld/nextcloud-client ) if you are familiar with Docker.

Thank you, I'll give a try.

[AlfHou]

Hi, is there still no systemd service provided? At the moment I am starting it manually each time I start the system (when I remember), which leads to a lot of conflicts between my machines

[SISheogorath]

Systemd service are global, not per user.

That's what systemd user services are for. They are per user. So no fancy root permissions required anywhere, you systemctl --user enable nextcloud.service. I would love to see this happen. Could maybe also ease the dependency on a systray, which not all desktop environments provide these days.

[mgallien]

That would most probably not work for Appimage package but for native distribution packages, that would be nice to have.
would you like to try doing it yourself?

[Tachi107]

@mgallien I agree. Debian packaging is well integrated with systemd units, and a user service would be easy to add. Where is the Debian repo located?

[mgallien]

@mgallien I agree. Debian packaging is well integrated with systemd units, and a user service would be easy to add. Where is the Debian repo located?

What would be nice is to contribute it to the desktop client repository such that any distributions can make good use of it.
Anyway, the Nextcloud Desktop client PPA repository is within the repository https://github.com/nextcloud/desktop/tree/master/admin/linux/debian .
Debina upstream repository is here https://salsa.debian.org/owncloud-team/nextcloud-desktop

[protist]

Here is a systemd service that works well for me so far. The client sometimes crashes for me, so I wanted a systemd job to automatically restart it. I haven't tested this service long enough to know if the client crashes with a failure. If not, then we could replace Restart=on-failure with Restart=always.

[Tachi107]

@protist maybe you could add ProtectSystem=full. Also I'm not sure if altering the file limit is really needed.

@mgallien sorry for not responding earlier, I was a bit busy. I'll prepare a PR as soon as I get home, not limited to Debian :)

[protist]

@Tachi107 Sorry, I probably should have made it more obvious, but I didn't write the service; I just found it randomly while searching. I was also confused by LimitNOFILE in the service. I'm also not sure that ProtectSystem does anything for user services?

[Tachi107]

I'm also not sure that ProtectSystem does anything for user services?

Yep, you're right, it's useless

[thomasmerz]

I also would appreciate when NC client on linux would be able to run in background as a demon (systemd-service) so that all files for all my local users (me, my wife and all my kids) on all my linux desktops would be able to sync with my Nextcloud server 24x7 - and not only when a user is logging in on one of my linux desktops.

[NL-TCH]

Here is a systemd service that works well for me so far. The client sometimes crashes for me, so I wanted a systemd job to automatically restart it. I haven't tested this service long enough to know if the client crashes with a failure. If not, then we could replace Restart=on-failure with Restart=always.

thanks, with flatpak use the following in the servicefile:
ExecStart=flatpak run com.nextcloud.desktopclient.nextcloud

[thomasmerz]

I forgot to mention that I want to have some NC clients for me, my wife, my kids running. Like "Syncthing - Open Source Continuous File Synchronization for …" - therefore I should use it like this:

systemctl --user edit --force --full [email protected]
systemctl --user edit --force --full [email protected]
systemctl --user edit --force --full [email protected]
systemctl --user edit --force --full [email protected]
…

[jospoortvliet]

Any chance you could share a bit of the use case for this? The majority of the clients' functionality seems intimately connected to a running user session (from right click menu in file manager to notifications). What does the systemd version of the client do that the one that starts on login into a desktop session doesn't? Is it just to avoid the initial sync of files when you log in? Would that be fixed by the virtual file system?

[protist]

@jospoortvliet There are several use cases listed above. For me, it's primarily the automatic restart when the client crashes (as I already mention above). The third comment above also mentions chaining units, e.g. depending on a network connection. Regarding interaction, as mentioned several times already in this thread, we are talking about a --user service, not a system service.

[jospoortvliet]

Ok, I see the point. It's useful on a multi-user system as files are always synced, instead of syncing when you log in. And it could restart the sync backend if it crashes. Crashes of the client are exceedingly rare, I haven't encountered them for literally years, but clearly that's different for other users. But yeah, if this was easy to set up, I'd use it on my linux system as I have 2 accounts, one of which I use for gaming and the other for work 😆

Would be nice to have files sync for work in the mean time. Though it can also cause latency, hum, complicated 🤣

Note that with virtual files (already on Windows, soon coming to Mac OS and hopefully some day to Linux) this seems a lot less relevant - the benefit (not having to wait for syncing when you log in) is nearly gone as it syncs far less, and can sync on demand. But of course you still have the ppl who experience crashes.

Anyhow, there's a PR, if somebody can help get this over the finishing line, this might be here soon:
#3510

If it's a ton more work, it gets harder, as we sadly have few users on Linux and even on Linux most systems are single-user so this would be a niche feature for a niche platform 😢

[protist]

Sorry @jospoortvliet I only just realised you were replying to the comment directly above you, not to the thread in general. I think I misunderstood, and some of my comments were a bit adjacent to this.

[stevenre3d]

I have a example use case: I have a SteamDeck and want to use Nextcloud to sync emulator saves between my devices. The SteamDeck boots into Valve's gamemode interface on device startup, but it's possible to "Exit to Desktop" which dumps you into KDE. I can install the Nextcloud flatpak there through Discovery, and I can add it to autostart in KDE, but of course then it's never launched unless I use "Exit to Desktop". I would like to enable it as a service behind gamemode by just saying systemctl enable --user nextcloudd.