On Thu, 29.01.15 17:20, Hoyer, Marko (ADITG/SW2) ([email protected]) wrote:
> Hi all, > > I'd like to realize a staged startup with systemd which is mainly about: > - starting up a static tree up to a final service > - the only job of the final service is to kick off the start of an additional > sub tree of units > > This kind of startup could be realized simply by adding an additional one > shot service which executes: systemctl start xxx.target > > My question now is: Is this the appropriate way for realizing this > or is there any other more elegant way. My problem with this > approach is that systemd executes a binary (systemctl), which > communicates with systemd just to queue a new job in systemd. Sounds > as if there should be a way which is a bit more direct ... This has come up before, for example here: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019187.html I think generally it is a better idea to push as many IO and CPU workloads into the kernel as possible, plus appropriate scheduling settings and let it figure out the rest, than trying to work around it by pushing things into the kernel only bit-by-bit, like you would do with such a "staged" startup. We already added support for applying different scheduling settings during startup then during normal operating to help with this. What I'd still like to see changed in systemd proper is permitting the user to control which job to execute first if multiple jobs are runnable at the same time. Currently the order is undefined (though not random). If you really want to do a "staged" boot-up then invoking "systemctl start --no-block" from a service is the option of choice I figure... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
