After= directive of systemd unit not working as expected

Question

So, I started breaking up my system init and creating some service files for things I want to be loaded after I login. It's the usual stuff like polybar, dunst and the rest of the things. Things do work, but I have some issues with my pywal setup. I've separated the dependencies into a separate .target called

theme.target

[Unit]
Description = Theme dependencies
BindsTo = xsession.target
Wants = pywal.service
Wants = i3.service
Wants = polybar.service
Wants = dunst.service

What I want to achieve is to have i3 (and the rest of the list for that matter) to load only after pywal.service is fully running and has finished execution of the start up script.

In .bin/pywal I do have a sleep of 10s

pywal.service

[Unit]
Description = Run pywal service responsible for color schemes
PartOf = theme.target

[Service]
ExecStart = %h/.bin/pywal

[Install]
WantedBy = theme.target

i3.service

[Unit]
Description = A tiling window manager
PartOf = theme.target
After = pywal.service
Requires = pywal.service

[Service]
ExecStart = /usr/bin/i3-msg restart

[Install]
WantedBy = theme.target

I might be confused here with what "successfully running" actually means, but i3 service I noticed restarts immediately once I run

systemctl --user restart theme.target

I'm then just watching status on all 3 services/targets and see that the i3 has restarted at the same time as pywal.service.

So basically what am I missing here and why does i3 not restart 10 seconds after pywal?

Edit: fixed a sentence to make more sense in this context based on the comment

score 1 · Accepted Answer · answered Mar 23 '22 at 17:57

There is a mismatch between your understanding of "successfully running" and systemd's idea. For services such as these, the "Type" is "simple", which means:

If set to simple (the default if ExecStart= is specified but neither Type= nor BusName= are), the service manager will consider the unit started immediately after the main service process has been forked off.

(My emphasis)

The subtle distinction here is one of timing: systemd considers the pywal unit started as soon as %h/.bin/pywal has been initiated while you'd like the subsequent units to wait until it is "has finished execution of the start up script".

As a result, the dependencies are started as soon as they're able (according to systemd), which means i3 will start very shortly after pywal starts, and pywal can sleep as much as it wants -- it has no further effect on the start time of i3.

I believe the proper answer here is to have pywal be of Type=Notify and to have it notify systemd when it is ready. See these for more about systemd-notify:

A workaround could be to modify the i3 unit with an ExecStartPre:

# ...
[Service]
ExecStartPre = /bin/sleep 10
ExecStart = /usr/bin/i3-msg restart
# ...

... to force the actual i3 executable to wait 10 seconds before running.

After= directive of systemd unit not working as expected

1 Answers1