When queuing a new job, this option controls how to deal with already queued jobs. It takes one of "fail", "replace", "replace-irreversibly", "isolate", "ignore-dependencies", "ignore-requirements" or "flush". Defaults to "replace", except when the isolate command is used which implies the "isolate" job mode.
If "fail" is specified and a requested operation conflicts with a pending job (more specifically: causes an already pending start job to be reversed into a stop job or vice versa), cause the operation to fail.
If "replace" (the default) is specified, any conflicting pending job will be replaced, as necessary.
If "replace-irreversibly" is specified, operate like "replace", but also mark the new jobs as irreversible. This prevents future conflicting transactions from replacing these jobs (or even being enqueued while the irreversible jobs are still pending). Irreversible jobs can still be cancelled using the cancel command.
This suggests a practical effect. Suppose you "hook units into the sleep state logic", using
sleep.target to pull them in. Your hook units do not have
DefaultDependencies=no, so they depend on
If you run
systemctl start reboot.target and then immediately
systemctl start suspend.target, it seems that your hook unit will stop
Requires=shutdown.target, so it should be stopped/cancelled as well. (
umount.target should not be cancelled).
I have verified a difference in behaviour along these lines and reported it as a defect in the systemd issue tracker.