[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 12:14:03 UTC 2016


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 
> <mailto: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> <mailto: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
>>>     <mailto: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 <mailto: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 <mailto: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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160426/284065e6/attachment.html>


More information about the systemd-devel mailing list