[systemd-devel] Require a systemd.unit to finish completely before other services(units) are started

george Karakou mad-proffessor at hotmail.com
Tue Apr 26 14:49:46 UTC 2016


You were really close, the correct answer is provided by mantas. Anyway driven from your thought i moved the script's execution to NetworkManager and i am now at the point i wanted. Though i have added 2 and something minutes to my startup process time.
Thanks.


--------------------
Ordering after the dispatcher won't help.
The dispatcher is not part of the initial transaction (e.g. pulled in
by multi-user.target.wants).

2016-04-26 14:14 GMT+02:00 george Karakou<mad-proffessor at hotmail.com>:

> It's actually NetworkManager-dispatcher whose actual job is -if i am not
> mistaken- to run some scripts after NetworkManager main process. Though i
> have configured NetworkManager-wait-online too but systemd's parallelizazion
> is unbeatable: services are started in parallel and i see other services
> that i have ordered after dispatcher finishing starting and dispatcher is
> still exec'ing my scripts.
>
> On 04/26/2016 01:00 PM, Mantas Mikulėnas wrote:
>
> Well, this sounds like your service should have some equivalent to
> NetworkManager's or systemd-networkd's "wait-until-online" tools.
>
> For example, there's NetworkManager-wait-online.service which blocks until
> NM has configured at least one connection fully, so other services can order
> against it (usually via network-online.target).
>
> (In fact, this sounds like you're talking about NetworkManager...)
>
>
> On Tue, Apr 26, 2016, 12:42 george Karakou<mad-proffessor at hotmail.com>
> wrote:
>> On 04/26/2016 09:35 AM, Andrei Borzenkov wrote:
>>
>> On Tue, Apr 26, 2016 at 9:27 AM, george Karakou
>> <mad-proffessor at hotmail.com>  wrote:
>>
>> Hi list, how are you all? I hope everyone is doing well.
>> I have a long starting unit that executes some(many actually) scripts and
>> with the parallel nature of systemd init process it doesn't fully start up
>> before some other units i have starting after it. Meaning "After="
>> directives in [Unit] section don't fully fill my needs here.
>> Is there a workaround?
>>
>> Is Type=oneshot an option?
>>
>> I understand that this demand somewhat violates the
>> parallel principle of the systemd init daemon but can it somehow be
>> serialized?
>> Thanks for any advice.
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
>> The service is of type dbus and i don't know if i want to break its
>> functionality(since its a system-service and registers a name on the bus).
>> But thanks.
>>
>>
>> On 04/26/2016 10:01 AM, Mantas Mikulėnas wrote:
>>
>> On Tue, Apr 26, 2016 at 9:27 AM, george Karakou
>> <mad-proffessor at hotmail.com>  wrote:
>>> Hi list, how are you all? I hope everyone is doing well.
>>> I have a long starting unit that executes some(many actually) scripts and
>>> with the parallel nature of systemd init process it doesn't fully start up
>>> before some other units i have starting after it. Meaning "After="
>>> directives in [Unit] section don't fully fill my needs here.
>> No, that's*exactly*  the case for After= directives. To disable
>> parallelization for some parts of the boot process, you use Before= and
>> After= – that's it.
>>
>> That said, if After=foo.service doesn't work properly, it usually means
>> foo.service is lying to systemd about when it has "finished starting". If
>> that's the case, you'd have exactly the same problems no matter what kind of
>> serialization you try to enable.
>>
>> If your megascript starts multiple daemons, then maybe it should be split
>> into several independent .service units, one for each daemon? If that's not
>> acceptable, try changing it to Type=notify, and make it use `systemd-notify
>> READY=1` once it's done.
>>
>> --
>> Mantas Mikulėnas<grawity at gmail.com>
>>
>> This service is vital for the networking part since it adds interfaces to
>> bridge, adds static arp entries and some other stuff and the point is to
>> have all this networking initialization in a central unit and then start
>> everything else, after the interfaces have been "upped". And since it is a
>> dbus service i don't know if i want to "break" it's functionality. Anyway i
>> don't see anything severely broken, like firewalls complaining of
>> non-existent interfaces after they have initialized, so i am aknowledging
>> this as not so high priority and i therefor thank you both.
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>

-- Why is it that all of the instruments seeking intelligent life in the 
universe are pointed away from Earth?





On 04/26/2016 05:37 PM, Mantas Mikulėnas wrote:
> On Tue, Apr 26, 2016 at 3:14 PM, george Karakou 
> <mad-proffessor at hotmail.com <mailto:mad-proffessor at hotmail.com>> wrote:
>
>     It's actually NetworkManager-dispatcher whose actual job is -if i
>     am not mistaken- to run some scripts after NetworkManager main
>     process. Though i have configured NetworkManager-wait-online too
>     but systemd's parallelizazion is unbeatable: services are started
>     in parallel and i see other services that i have ordered after
>     dispatcher finishing starting and dispatcher is still exec'ing my
>     scripts.
>
>
> Because systemd _does not know_ that the dispatcher daemon is doing 
> something in the background.
>
> You seem to be convinced that systemd is doing some trickery to 
> parallelize NM. Meanwhile it's the exact opposite.
>
> -- 
> Mantas Mikulėnas <grawity at gmail.com <mailto:grawity at gmail.com>>
After moving the dispatcher script to NetworkManager i have the result i 
was after. The startup process is delayed until the service is fully 
started. Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160426/30f9fc11/attachment.html>


More information about the systemd-devel mailing list