Sample Header Ad - 728x90

Where is the Systemd ordering cycle occurring?

1 vote
1 answer
184 views
I have to Systemd units a service and a socket. The desired behavior is that when I start the socket the service will start first followed by the socket and when either is taken down they should both go down. The service binds to the socket before the socket unit starts which is why I have it as a notify service so it doesn't report as started until it has the bind on the socket. Here are the files for the two Units.
#rustyvxcan.service
[Unit]
Description=Docker VXCAN plugin Service
#PartOf=rustyvxcan.socket
    
Before=docker.service
After=network.target
    
[Service]
Type=notify
ExecStartPre=/usr/bin/mkdir -p /run/docker/plugins
ExecStart=/home/braedon/.cargo/bin/rustycan4docker
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
#rustyvxcan.socket
[Unit]
Description=A network plugin for vxcan
Before=docker.service
AssertPathExists=/run/docker/plugins
Requires=rustyvxcan.service
After=rustyvxcan.service

[Socket]
ListenStream=/run/docker/plugins/rustyvxcan.sock
RemoveOnStop=True

[Install]
WantedBy=sockets.target
The error message is as follows.
Sep 19 16:50:38 localhost systemd: rustyvxcan.service: Found ordering cycle on rustyvxcan.socket/start
Sep 19 16:50:38 localhost systemd: rustyvxcan.service: Found dependency on rustyvxcan.service/start
Sep 19 16:50:38 localhost systemd: rustyvxcan.service: Unable to break cycle starting with rustyvxcan.service/start
Sep 19 16:55:09 localhost systemd: rustyvxcan.socket: Found ordering cycle on rustyvxcan.service/start
Sep 19 16:55:09 localhost systemd: rustyvxcan.socket: Found dependency on rustyvxcan.socket/start
Sep 19 16:55:09 localhost systemd: rustyvxcan.socket: Unable to break cycle starting with rustyvxcan.socket/start
From the resources I seem it means the cycle is only happening with these two files and I can clear the error by removing the After line from the .socket file but then they boot simultaneously and the executable for the service fails. I could probably resolve this simply by adding a sleep to the socket however I don't see enough dependency information here to cause a cycle. I have tried clearing out /{lib,etc}/systemd/system of the service and socket file and reinstalling the ones pasted here just to make sure older versions weren't running, and of course running systemctl daemon-reload regularly while modifying it. But I cant seem to figure out why specifying after breaks the dependency graph even after stripping out dependencies from the service file. Where is the loop happening that I am missing?
Asked by Braedon (13 rep)
Sep 20, 2024, 12:17 AM
Last activity: Sep 22, 2024, 08:45 AM