Hi, We are starting many services between basic.target - multi-user.target at the same time and due to this we are suffering from following two subjects. What can we do to overcome these problems?
1) We would like to start a subset of services that are scheduled to start between basic.target - multi-user.target before the rest and there is no built in way to satisfy our needs. a) We could use Before=, After= on services but the downside of this kind of dependency is we have to edit every single service file with Before=, After= directive. This is not the best option when the subset of services we would like to start early might change between hardware or product configuration. b) The ongoing patch http://lists.freedesktop.org/archives/systemd-devel/2014-March/018220.html is promising but it seems to be stopped. Any reason? c) A service running before basic.target and queriying systemd with "systemctl show -p [Wants Requires] default.target" and adding Before=, After= dependency on services on runtime. Doesn't seem so efficient. 2) Due to starting too many services and due to having frequent context switches (flushing of caches), we see that boot time is longer than booting services sequentially. a) Proposing a configuration to limit the number of jobs that are in "activating" state. b) "nice" value of the services can be changed to prioritize things randomly but then we have to revert back the nice value once the boot is completed. Doesn't seem so easy. We are aware that our problem is mostly embedded platform specific. We could solve our problem staticly with what systemd offers but a static solution that is customized for one hardware is not the best solution for another hardware. Having static solutions per hardware is extremely hard to maintain and we would like to solve this problem upstream instead of downstream magic. Thanks, Umut _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
