2

The Type=oneshot unit A.service is started hourly by A.timer and it Wants=B.service, but runs Before=B.service. Unit B.service is also Type=oneshot. The requirement here is that their processes should never overlap at run time (oneshot ensures exactly that), all great so far. Now imagine a scenario where both A and B together run for more than an hour (time between A.timer fires). There are two possibilities here:

  1. A runs more than an hour, then although A.timer wants to fire and it probably does, regardless, another instance of A will not be started until the first one finishes as service instance uniqueness is one of fundamental principles in systemd. I believe it will be merely queued. Again, all great so far, we have no risk of overlapping processes at run time here.
  2. A runs long enough, so that B, which runs afterwards, also runs long enough to exceed one hour in total, and as a result, A.timer fires to start new A while B is still running. That's where we run into a process overlap because there is no After=B.service in A.service as there is already Before=B.service.

My question is, basically, whether it is valid to even have both After=B.service and Before=B.service in A.service in the first place? And, of course, would it resolve the overlapping issue described in the second possibility as I theoretically expect? Is there any other systemd-way to solve this issue (e.g. I don't want to get involved with error-prone lock file bloat)?

Alexander Shukaev
  • 131

1 Answers1

3

If you create a Before= and an After= in your A.service file, you will get an error:

A.service: Job B.service/start deleted to break ordering cycle starting with A.service/start

Because Systemd doesn't want to have both of those dependencies on the same unit. I don't think that any of the Condition...= from man systemd.unit that Michael mentioned are well-suited for the task that you are trying to accomplish, unless your commands do create and then clean up their own files. The way I see it, you have two main possible solutions:

  1. Create an ExecCondition= in your A.service that runs a command to check if B.service is running. This is a bit tricky to do with just ps and grep from within your unit file, so you'd probably want to execute some external script, but you already said you wanted to avoid a messy lockfile so that is probably not ideal.
  2. Use the messy lockfile solution that you mentioned that you didn't want to use
  3. Move your second command out of B.service and into a ExecStopPost= option in A.service. This will cause the second command to run only after the first command has stopped. It will also prevent a new A.service from running before the first one completely finishes. I believe that this accomplishes all of your desires, since the A.service command and B.service command will never be run at the same time, two A.service commands will never be run alongside each other, and new executions will just be queued.

Here is the unit file that I used to test option 3:

[Unit]
Description = A.service for serverfault
[Service]
Type = oneshot
# A.service command
ExecStart = /usr/bin/sleep 3 
# B.service command
ExecStopPost = /usr/bin/sleep 30

And then tested using systemctl start A.service repeatedly in multiple terminal windows, monitoring the progress of which processes were actually running at any given moment with ps.

Bofa Deez
  • 231
  • 2
  • 3