Similar to system units, user units are located in the following directories (ordered by ascending precedence):
/usr/lib/systemd/user/ where units provided by installed packages belong.
~/.local/share/systemd/user/ where units of packages that have been installed in the home directory belong.
/etc/systemd/user/ where system-wide user units are placed by the system administrator.
~/.config/systemd/user/ where the user puts their own units.
But then in the next section says…
All the user units will be placed in ~/.config/systemd/user/.
My unit is currently in /usr/lib/systemd/user/, and indeed when I invoke systemctl --user enable syncthing.service I get
Failed to enable unit: Unit file ~/.config/systemd/user/default.target.wants/syncthing.service does not exist.
Can anyone explain what the wiki means by “Similar to system units, user units are located in the following directories”, if, in fact, the only place user units can be is ~/.config/systemd/user/default.target.wants/?
The service file goes to ~/.config/systemd/user/syncthing.service. Then, do a systemctl --user reload, and the to start, systemctl --user enable --now syncthing
From what I can gather, if you want the syncthing.service to start whenever any user logs in, then you should place the service file in /etc/systemd/user/. You would then enable that service using systemctl enable syncthing.service. Whenever any user logs in, that service will start for them.
If you want the syncthing.service to start only when you log in, then you should place it in your home directory’s .config folder, as per @mithrial’s instructions above, and enable it with the --user flag. Enabling the service will then symlink it into the appropriate .wants subdirectory, and it will run only when you are logged in.
I have lots of systemd timer jobs that I run as a user - here’s the tree of my ~/.config/systemd/user directory:
Edit: I just had a look in Pamac at the syncthing package, and their site, and I think there might be a very simple solution to your problem which doesn’t require setting up systemd services. Just add it to autostart via System Settings => Autostart => Add Application (which is the method recommended at their site).
If you want to do it the (slightly) harder way using systemd, then the relevant systemd service files are already installed (I am assuming you installed syncthing from the Manjaro repositories). You just need to do the following, as per the instructions at Starting Syncthing Automatically — Syncthing documentation:
Enable and start the service. Replace “myuser” with the actual Syncthing user after the @:
For reasons I am at a loss to explain, doing that (using /bin/syncthing) places a syncthing-gtk (which I don’t even have anymore) in the autostart. I think the .desktop for syncthing has gotten messed up somewhere in my long history of using it.
I could, but I’d rather understand why it’s not working as expected first. Maybe I’ll turn to making the directory as a last resort. Might have to go back through the guidance with a fine toothcomb and see if I’ve missed something.
Because, user services that are started are linked in default.target.wants. The enable command, basically only creates a link to a user service file in /usr/lib/systemd/user/ or ~/.config/systemd/user/ in this specific folder.
I use syncthing to move data to and from a firewalled production server and usually syncthing just works.
I have also gone to great length to keep the service private - as in using a private discovery service.
When a package installs a service - whether that is user or system it is (usually) placed /usr/lib/systemd.
When you enable a user service - it will be placed in folder in your ~/.config/systemd - a folder matching the target run level - in the case of syncthing the folder is default-target.wnats.
When a user service is placed in /usr/lib/systemd/user it is a template service - you need to activate for your user - and should be needless to say never use sudo with user services - this is the only way the system will know which user you are enabling the service for - it is only a template.
systemctl enable --now syncthing@$USER.service
If you omit the @username you will get a service not found - because it does not exist
Only in my case, it doesn’t. It just responds that there is no such service in that folder.
This worked to a point (so thank you - I’ve learned something new at least), in that it seemed to create the symlink in the right place, but it created a symlink to the syncthing@ service. Syncthing documentation says…
Running Syncthing as a system service ensures that Syncthing is run at startup even if the Syncthing user has no active session. Since the system service keeps Syncthing running even without an active user session, it is intended to be used on a server.
… which is not my use case. I’m trying to run it as a user, for which I need to start syncthing.service, not syncthing@.service.
You are not correct - if you are intending to run as a user - you setup syncthing@username.service.
Syncthing can be setup in a wide array of use cases and the questions you ask and the answers given my not correctly reflect your usecase.
The most basic use case is to run syncthing as a user service on two or more systems thus syncing files between the two.
The backdraw to this is that both systems must be up and connected to eachother for a sync process to be executed.
If you want to create a common sync location where you will sync selected files - you will need a server system and setting that up is slightly different - depending on how public you want it to be.
Create the user who should run the service, or choose an existing one. Probably this will be your own user account.
(Skip if your distribution package already installs these files, see above.) From git location copy the syncthing.service file into the load path of the user instance. To do this without root privileges you can just use this folder under your home directory: ~/.config/systemd/user/.
Enable and start the service:
systemctl --user enable syncthing.service systemctl --user start syncthing.service
It appears you are using the official documentation on syncthing - am I correct?
From what I can understannd you are also ignoring the fact that the service must be started with a username.
Running Syncthing as a system service ensures that it is running at startup even if the user has no active session, it is intended to be used on a server. Enable and start the syncthing@myusername.service where myusername is the actual name of the Syncthing user.
– Syncthing - ArchWiki
Bit of both (Syncthing docs and Arch-Syncthing), but from the Arch Wiki it would be…
User service: on login
Running Syncthing as a systemd user service ensures that Syncthing only starts after the user has logged into the system (e.g., via the graphical login screen, or ssh). This method is intended to be used on a (multiuser) computer. To run the user service, start/enable the user unitsyncthing.service (i.e. with the --user flag).
Did you install syncthing using the package manager? or by some other means?
I have used syncthing for years and I know other members do as well - if you do it right - it just sync things - sligt joke intended
I would appear there is either inconsistency in the documentation you are using or you are overlooking something. Perhaps I didn’t understand well enough first time around …
For the system wide service @ character tells that it must be run with an argument - in this case a username - this will run as a system wide service and must be installed with sudo - and loose the --user argument.
Activated with a command like (to have it work with a user not logged in use the linger option as described in the wiki)
The user service in the user tree does not require the @ as the call - no sudo - but with the –user argument will place the activation link in your user’s home and only be activated when you login - activate like this
Technically you can use either one or the other - the result is the same but with the first can use the linger option to activate with the user actually logging in - at least - that is how I understand it.
Yes, all normal there. The only oddity I can think of that might explain things is that I also used to have Syncthing-GTK installed as a helper, but that stopped working last update so I uninstalled it. I do still have the normal synthing package though, and when I run it from the command line (just syncthing) it runs flawlessly with all my original syncs set up.
The problem just seems to be that enabling the service via systemctl enable --now --user syncthing.service doesn’t seem to behave as expected.
My (uneducated) guess is that there must be something wrong with the syncthing.service unit file (posted above) on my installation that’s causing it to misbehave when run.
Also (unrelated, but annoying, given the alternative) I don’t have the syncthing-start.desktop file as the Synthing docs suggest I should have, but I’ve downloaded that file directly from syncthing’s git and put it in autostart. That also works, so I have a temporary fix, but I don’t like not knowing what’s wrong…
I don’t use any desktop apps - simply launching a web brower at the address will open a configuration page
http://localhost:8384/
There is nothing wrong with it - it is exactly the one I use - and it works as expected. I am running my own discovery server and sync service as I want to keep it private to the company I work for.
