*.service switch to Type=simple systemd service

[fcrozat]

Use Type=simple service, since btrfs actions can take a while, which is in contradiction with oneshot systemd service type definition.

[fcrozat]

It will cause the state of this systemd service to be always in "activating" mode and not in "running" mode. This might cause systemd to decide to terminate the service after some time because it didn't "start" properly.

Moreover, if somebody wants to "manually" trigger one of the services, systemctl start commands will block (it shouldn't). This is problematic when long running service, like balance.

[kdave]

Merged, thank you.

[comio]

@kdave and @fcrozat

I think that oneshot is still necessary in order to keep services starting order. With simple the service will go directly to "started" status triggering the waiting services ("after" clause). I'm sorry, but I remembered just now why I decided to use oneshot instead simple (§"Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units.") "TimeoutSec=infinity" clause can help in oder to avoid to kill very long tasks. Sorry again.

[fcrozat]

If you want to maintain order, uses After with a target started on task completion, not oneshot

[comio]

not sure of your proposal.

What about if I register timers for more services (ie, scrub and defrag) at the same time? defrag service has "after=scrub" of course. How can I say to derag to wait scrub service completion? The defrag will be blind to the post-start triggered target because "after" declare a loosely dependency ("After=b" => "If b is schedule, the start this service after b, otherwise don't care about b"). I now that this is not the correct place to learn, but can you provide an example of your solution?

ciao

luigi

[fcrozat]

ExecStopPost=systemctl start scrub-complete.target (with a corresponding .target file) and then you call schedule things using After=scrub-complete.target

(untested)

[comio]

but what about if I haven't enabled scrub service? I should inject manually srub-complete.target. Too complexity for the end-user. I'm sorry, but I think that oneshot + infinite timeout (with a long "starting" status) is still better and cover the user required semantic.

[fcrozat]

FYI, After is not blocking anything, Targets are just synchronisation point. But it is your call, of course

[comio]

I know. sorry in my mind I had "wanted" instead "after" (I should sleep a little bit). The question is that if I in the systemd execution graph both scrub and defrag serivces, using ExecStartPost with the target doesn't permit to give the correct precedence between services. BTW, we need to sync manually scripts with locking in order to start to many jobs on the same disk. (I have a low quality patchset for this... I can produce another PR for discussion if you want).