<div dir="ltr">Hi, <div><br></div><div style>My concern was being forward compatible with systemd and you have addressed my concern. </div><div style><br>Thank you.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Sat, Mar 23, 2013 at 3:55 AM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Fri, 08.03.13 14:12, Umut Tezduyar (<a href="mailto:umut@tezduyar.com">umut@tezduyar.com</a>) wrote:<br>
<br>
> Hi,<br>
><br>
> What would be the advantage of placing an early boot up script in between<br>
> local-fs.target/sysinit.target OR in between<br>
> sysinit.target/basic.target?<br>
<br>
</div>That's a very good question. This hopefully gives a bit of an explanation:<br>
<br>
<a href="http://www.freedesktop.org/software/systemd/man/bootup.html" target="_blank">http://www.freedesktop.org/software/systemd/man/bootup.html</a><br>
<br>
The difference is not that big actually. Basically, sysinit.target is<br>
supposed to be the barrier before which all the OS vendor system<br>
initialization stuff is finished. And then basic.target is the<br>
barrier before normal user services are started. In between the two we<br>
initialize the sockets currently, and only really those. i.e. units that<br>
belong to the user, but should run before the actual services are<br>
started.<br>
<br>
I plan to introduce "paths.target" and "timers.target" in a similar<br>
fashion soonishly. Also, as soon as we have kdbus support in systemd we<br>
will do bus name registration the same way. I.e. there will be a new<br>
unit type ".busname" for establishing bus names, and they by default are<br>
established between sysinit.target and busnames.target or so.<br>
<br>
Now, some of systemd's own services aren't entirely consistent between<br>
what it puts before sysinit.target and what before basic.target. But<br>
this is something we should clean up.<br>
<br>
But in general the rule is: you should place your early-boot stuff<br>
*before sysinit.target*. And your late-boot stuff *after<br>
basic.target*. And leave everything in between for .socket, .path,<br>
.timer, .busname units.<br>
<div class="im"><br>
> I cannot decide what should be the ordering for some early initialization<br>
> "oneshot" services I have in my embedded system. These services makes some<br>
> simple preparations that were previously in /rcS.d/. Dropped support for<br>
> /rcS.d/ in systemd was placing these services as After=sysinit.target and<br>
> WantedBy=sysinit.target (and I am not entirely sure but possibly<br>
> Before=basic.target). I could place them as systemd did before or I could<br>
> place them as After=local-fs.target and Before=sysinit.target.<br>
><br>
> Since my embedded system doesn't have login prompt, I don't see the<br>
> difference between basic.target and sysinit.target other than socket<br>
> activation. Even then, a service that is socket activated has<br>
> DefaultDependency=yes (It will start after basic.target).<br>
><br>
> To summarize, where are users encouraged to place their early boot up<br>
> initialization services (ex: setting up the bandwith on a NIC)?<br>
<br>
</div>sysinit.target!<br>
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering - Red Hat, Inc.<br>
</font></span></blockquote></div><br></div>