On Fri, 05.09.14 13:52, Viswambharan, Vibin (V.) (vvi...@visteon.com) wrote:
> 1/ Is there a recommended way to re-organize the boot target order ( > I don't see there is a way to fit my userlevel application > executables or deamons needed for early functionality to be > associated with these "primitive target" appearing in the boot > chain". Well, the unit files are all just text files, you can mostly just edit them and adjust to your needs. That said, the default unit files contain pretty minimal dependencies only, just the stuff that is really needed. Hence optimizing the dependencies is not rally typically necessary or sometimes even possible. Usually, if there's something you want to run earlier than the default, you can move them into the early boot process, but if you do this you need to write that program in a style that it is capable of working in such an early-boot environment. Among other things this means no access to /var and suchlike, no persistent storage. Also, no access to D-Bus, and so on. > 2/ Is there a way to define custom target like "early-boot.target" > and can be placed well on top of these special targets which can be > used to start my user space applications that needs to be started > well early during the boot process ( for example my full functional > UI to be available within 8 sec from a cold boot which is has a X11 > dependency) . So I mean that I need a way to start the X11 and my UI > executable soon after systemd gets initialized and very early during > the boot process.Currently the service files for the X11 and UI > after associated with the basic.target and now the service > activation can happen only around 7 sec after power on and when the > basic.target is activated. You can add such a service to the normal target, but set DefaultDependencies=no for it. If you do the service will not be ordered after basic.target (which is the default), thus run in the early-boot mode described above. However, be careful, as pointed out above. > 3/ Is there any special consideration to disable these special > targets like (swap.target,local-fs target if they are not used in > the embedded devices?). Well, they cost nothing if there are no swaps or local file systems to mount. I'd suggest not to bother. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel