0

I have two service files (serva and servb) as shown below. I want serva to start first (on boot, once network is available), and servb to start only after serva has started. This should be easy, but after playing with several service file parameters I'm still facing this error:

serva.service: Job servb.service/start deleted to break ordering cycle starting with serva.service/start

How do I fix servb.service to achieve what I want?

the serva.service file is:

[Unit] Description=Test Service A (serva) ConditionPathExists=/usr/local/serva ConditionFileIsExecutable=/usr/local/serva/serva ConditionPathIsReadWrite=/tmp Requires=network.target After=network-online.target postgresql.service multi-user.target Wants=postgresql.service [Service] Type=forking PIDFile=/run/serva.pid WorkingDirectory=/usr/local/serva ExecStartPre=/bin/sleep 10 ExecStart=/usr/local/serva/serva SuccessExitStatus=129 200 [Install] WantedBy=multi-user.target

The servb.service file is:

[Unit] Description=Test Service B (servb) ConditionPathExists=/usr/local/servb ConditionFileIsExecutable=/usr/local/servb ConditionPathIsReadWrite=/var/tmp Requires=serva.service After=serva.service [Service] Type=forking PIDFile=/run/servb.pid WorkingDirectory=/usr/local/servb ExecStart=/usr/local/servb/servb SuccessExitStatus=129 200 [Install] WantedBy=serva.service

I tried modifying servb to use PartOf=haast.service instead of Requires=, but no change in behaviour. I suspect the 10 second delay in serva is contributing to the problem (but this is essential).

Improve this question

1 Answer 1

Reset to default
0

Stop ordering it after multi-user.target.

All units which are wanted by a target, are also implicitly ordered before that target (so that the target itself only becomes 'ready' once all its constituent units are ready). An explicit "After" overrides this – but only for that particular unit, not transitively, so you have:

  • serva after multi-user (explicit After)
  • servb after serva (explicit After)
  • multi-user after servb (implicit from target having Wants)

If the goal was to have serva run "after everything else" – don't do that, since it clearly contradicts the "After=serva" on servb.

I suspect the 10 second delay in serva is contributing to the problem

It's not. Dependencies are not based on times, so a dependency cycle is still a dependency cycle regardless.

this is essential

If it's essential, then a comment is also essential, where you explain for the next admin why the sleep was deemed essential – i.e. 1) what exactly is being waited for, and 2) why a fixed delay was thought to be appropriate instead of declaring appropriate dependency ordering.

Improve this answer
2
  • You pointed out some import not-to-do's....but I'm left wondering what is best way to solve this. Commented May 13 at 15:53
  • The best way to solve this is by removing After=multi-user.target. It is most likely what's directly causing the problem. Commented May 13 at 19:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.