Switching to type=simple broke the after= effect

[super7ramp]

@fcrozat

after= was used in the service file in order to prevent e.g. btrfs-balance and btrfs-trim from running at the same time because this leads to performance issues (see boo#1063638).

This worked well because services were oneshot, i.e. with no real active state: inactive → activating → inactive.

Now, since commit 64be9c7: "*.service switch to Type=simple systemd service", services are simple, which gives something like: inactive → activating → active → inactive.

So now the after= field, which only prevents to start until the listed services haven't finished starting up, does not ensure that the btrfs operations are not running in parallel.

Unless someone has a better solution, I propose to revert commit 64be9c7.

[fcrozat]

This kind of requirement can't be properly implemented in systemd (and using the activating state with oneshot is wrong in that regard). This should be better handled in the script themselves.

[super7ramp]

Sorry, I don't see the problem in using oneshot services for that.

I don't understand why we should care to add a lock or something in the shell scripts to prevent btrfs operations from being simultaneously run when after= just does the job for us.

I don't see the problem of having long duration for a oneshot service either. I haven't seen any recommendation in the doc about that.

[sten0]

@fcrozat, would you please provide a citation? It sounds like you're saying that systemd doesn't support sequential execution in a strict series, when the combination of Before= and After= seems to indicate otherwise. (See systemd.unit(5) § "Before=, After=")

[fcrozat]

I don't see the problem of having long duration for a oneshot service either.

Any start of this service through systemctl will be blocked (systemctl will be blocked) until completion (which can last hours for balance) and cancelling systemctl will cause the service to be terminated. systemctl calls should not be blocking.

It sounds like you're saying that systemd doesn't support sequential execution in a strict series, when the combination of Before= and After= seems to indicate otherwise.

Just using After and Before will not garantee you don't get jobs run in parallel (it only creates synchronisation points in the startup order). And my statement was in the context of doing the btrfs job in the "active" state (when using Simple).

[kdave]

In 0.5 tasks are serialized, so the Type=simple is ok. Closing.