User systemctl services won't enable

mashton · May 3, 2025, 6:37am

HI,

I have an issue with --user systmctl services.

Even if I enable them with systemctl --user enable foo.service (take syncthing.service as an example), the service does not start on boot or login.

The service starts fine if I manually issue a systemctl --user start foo.service.

Output of systemctl --user status foo.service gives:

systemctl --user status syncthing.service
○ syncthing.service - Syncthing - Open Source Continuous File Synchronization
     Loaded: loaded (/usr/lib/systemd/user/syncthing.service; disabled; preset: enabled)
    Drop-In: /home/mashton/.config/systemd/user/syncthing.service.d
             └─override.conf
     Active: inactive (dead)
       Docs: man:syncthing(1)

This problem exists for all --user services either from installed apps, or made by me.

What am I missing?

BTW, for illustration the service file for syncthing.service is:

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

# Elevated permissions to sync ownership (disabled by default),
# see https://docs.syncthing.net/advanced/folder-sync-ownership
#AmbientCapabilities=CAP_CHOWN CAP_FOWNER

[Install]
WantedBy=default.target

# /home/mashton/.config/systemd/user/syncthing.service.d/override.conf
[Install]
WantedBy=multi-user.target

Note my override edit to change WantedBy in an effort to get this working.

BluishHumility · May 3, 2025, 4:21pm

What display manager is in use?

The user instance of systemd is typically started when you log into a graphical session or certain types of login shells (it’s usually started by PAM when you log in). If you are using a display manager that doesn’t have proper systemd integration, or are logging in from a TTY or something, you may need to set this up on your own.

manfredlotz · May 3, 2025, 4:55pm

Assuming that you have installed syncthing from extra I recommend

sudo systemctl enable syncthing@mashton.service

Delete the syncthing related stuff in ~/.config/systemd/user/

BluishHumility · May 3, 2025, 5:16pm

I don’t think Syncthing is actually the problem, it was just used as an example. The issue appears to be related to their user session.

The way they are doing it should work fine. I tested on my system as well; the built-in service file works as-is.

❯ systemctl --user enable --now syncthing.service
Created symlink '/home/jeremy/.config/systemd/user/default.target.wants/syncthing.service' → '/usr/lib/systemd/user/syncthing.service'.


❯ systemctl --user status syncthing.service 
● syncthing.service - Syncthing - Open Source Continuous File Synchronization
     Loaded: loaded (/usr/lib/systemd/user/syncthing.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-05-03 11:55:13 EDT; 11s ago
 Invocation: dcb573e4ba2f4419bdf4ce272dcd197b
       Docs: man:syncthing(1)
   Main PID: 12827 (syncthing)
      Tasks: 27 (limit: 76486)
     Memory: 69.8M (peak: 72.1M)
        CPU: 566ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/syncthing.service
             ├─12827 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
             └─12857 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0

May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: Device XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX is "xxxxx-x" a>
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: Device XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX is "xxxxx-x" a>
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: Device XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX is "xxxxx-x" a>
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: Device XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX is "xxxxx-x" a>
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: TCP listener ([::]:22000) starting
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: QUIC listener ([::]:22000) starting
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: Ready to synchronize "Default Folder" (default) (sendreceive)
May 03 11:55:13 nuc syncthing[12827]: [WSECY] INFO: Completed initial scan of sendreceive folder "Default Folder" (default)
May 03 11:55:15 nuc syncthing[12827]: [WSECY] INFO: Established secure connection to XXXXXXX at 192.168.0.13:22000-192.168.0.2:22000/tcp->
May 03 11:55:15 nuc syncthing[12827]: [WSECY] INFO: Device xxxxx-x client is "syncthing v1.29.5" named "xxxxx-x" at 192.168.0.13:22000-1->

Although that drop-in file should be scrapped. multi-user.target should not be used for a systemd user service.

manfredlotz · May 3, 2025, 5:46pm

But then he should show the commands and their outputs. Otherwise it is a guessing game.

Example:

systemctl --user enable --now something.service
systemctl --user status something.service

BluishHumility · May 3, 2025, 7:04pm

Yes, that is pretty much exactly the example they gave.

manfredlotz · May 3, 2025, 7:05pm

I missed the output of the enable.

Before I believe that the services with --user don’t work I would see a test with a simple service file.

One test he could do is the following

Create a ~/.config/systemd/user/hello.service file with this content

[Unit]
Description=Run hello

[Service]
Type=oneshot
ExecStart=/usr/bin/echo "Hello from echo..."

[Install]
WantedBy=default.target

Then I like to see ls -l ~/.config/systemd/user/hello.service

Run systemctl --user enable --now hello.service

Show output

Run systemctl --user status hello.service

Show output

If all is ok so far then reboot and after login into user mashthon run

systemctl --user status hello.service and show output

mashton · May 3, 2025, 8:45pm

Hi,

Thanks for the replies.

Yes, I was merely using syncthing as an example.

My setup is lightdm logging into i3wm.

@manfrediotz, thank you for the help with setting up a minimal test case. Results are below:

ls -l ~/.config/systemd/user/hello.service
.rw-r--r-- 133 mashton  3 May 21:41  /home/mashton/.config/systemd/user/hello.service

Then

systemctl --user enable --now hello.service
Created symlink '/home/mashton/.config/systemd/user/default.target.wants/hello.service' → '/home/mashton/.config/systemd/user/hello.service'.

systemctl --user status hello.service
○ hello.service - Run hello
     Loaded: loaded (/home/mashton/.config/systemd/user/hello.service; disabled; preset: enabled)
     Active: inactive (dead)

May 03 21:42:37 starbook systemd[1192]: Starting Run hello...
May 03 21:42:37 starbook echo[168164]: Hello from echo...
May 03 21:42:37 starbook systemd[1192]: Finished Run hello.

Note the presence of “disabled; preset enabled”.

Now I will post this post, do a reboot and then post the output of one more status command.

see you after the break…

mashton · May 3, 2025, 8:47pm

System has rebooted.

Final test

systemctl --user status hello.service
○ hello.service - Run hello
     Loaded: loaded (/home/mashton/.config/systemd/user/hello.service; disabled; preset: enabled)
     Active: inactive (dead)

As described.

I hope this is sufficient, as well as necessary, to make you a believer…?

mashton · May 3, 2025, 9:09pm

Ahha!

I have figured it out and fixed it.

The problem was that I use GNU Stow to manage my dotfiles. As well as stowing my service definition files, I had also included the default.target.wants folder in the stowed dotfiles folder.

When this is deployed, it makes a symlink in .config/systemd/user to the default.target.wants folder. In which further symlinks are then created by systemd, when I enable user services.

I don’t understand why this causes the services to fall back to being disabled, but it does.

I unstowed the folder which removed the symlinked default.target.wants folder. I then reneabled the hello.service which created the d.t.w folder and the appropriate symlink within it.

DId a reboot and the service was running.

All is well.

Thanks for the help and the interest, I really appreciate it.

manfredlotz · May 4, 2025, 3:21am

So, it was good I wasn’t a believer as there was something (stow) you didn’t mention before.

manfredlotz · May 4, 2025, 3:45am

Compare the symlinks before and after using stow

find ~/.config/systemd/user -name hello.service -ls

then you (we) might get an idea.

My simple guess is that stow kills the symlinks which must be absolute (path wise).
After some thinking about the symlinks I have to say that I am not 100% sure if the path must be absolute in the symlink

system · May 6, 2025, 3:46am

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.