18.09.2015 17:58, Vivenzio Pagliari пишет:
However, these additionally added services are not started, when trying to reach multi-user.target. After boot, I can see that the dependencies where added correctly (e.g. doing "systemctl list-dependencies multi-user.target" lists the newly created services as dependencies, but they remain inactive).
Transaction is computed when job is initially submitted. If you add new unit definition they won't automatically become part of transaction. It may be possible to cancel and resubmit it, it should then pick up units that are not yet started, but I am not sure how safe it is.
I suspect that something is wrong with this approach, but I do not understand, what. My assumption is that during boot it is not supported to fiddle with the "dependency graph" dynamically (i.e. before the boot reaches its final unit). Is this correct? If so, is there a rationale for that? If this approach is wrong, what would be a better systemd-based approach of solving such a problem of "starting SW that is available only later during bootup"?
One possibility is to add newly detected units as dependency of common target and simply run "systemctl start this.target" as ExecPost after scan is complete.
-Vivenzio _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
