[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