multipathd.service: add socket as dependency #72
Conversation
Add multipathd.socket as a weak dependency. Before this commit, systemd knows
the start order (socket -> Service) due to the After=multipathd.socket but no
explicit dependency is made. This solves the issue if a user attempts to start
the socket after the service like so:
systemctl stop multipathd.service multipathd.socket
systemctl start multipathd.service multipathd.socket
An error will be noted in journalctl, and the socket will be left in an
inactive state if you query it with systemctl status multipathd.socket.
|
Hm. Users may want to start the service without starting the socket. Socket activation isn't mandatory. Manually starting the socket after the service is a user error, and a error message is justified in this case. @bmarzins, your opinion? |
I don't have super strong feelings about this, but having the ordering without the dependency was intentional. Some multipath commands will attempt to contact multipathd, and I can certainly see someone not wanting multipathd to get started in this case. My preference is to leave it as is. |
|
That makes sense. Thanks for considering the change! Feel free to reject this PR. The one thing I'd like to add to this thread is that I'd like to see a robust way to avoid the socket going into an inactive state, even when a user attempts to start the socket when it's already active. If you have any tips on that, I'd love to try it out. |
|
I don't think that's possible. The socket unit will fail to start if the socket has already been opened by multipathd. I don't think you can do anything about that. You'd need to ask a systemd expert. This is out of my systemd comfort zone. |
|
That's my understanding too. Thanks for chiming in! |
|
Closing. |
Add multipathd.socket as a weak dependency. Before this commit, systemd knows the start order (socket -> Service) due to the After=multipathd.socket but no explicit dependency is made. This solves the issue if a user attempts to start the socket after the service like so:
An error will be noted in journalctl, and the socket will be left in an inactive state if you query it with systemctl status multipathd.socket.