[systemd-devel] EXT :Re: Systemd dependencies
Andrei Borzenkov
arvidjaar at gmail.com
Tue Dec 11 16:42:46 UTC 2018
11.12.2018 15:40, Boyce, Kevin P [US] (AS) пишет:
> So there is no way to delay everything in a target until a previous transaction is completely finished?
>
No. There is no such thing as "everything *in* a target". There is
"everything *before* target".
> -----Original Message-----
> From: systemd-devel <systemd-devel-bounces at lists.freedesktop.org> On Behalf Of Andrei Borzenkov
> Sent: Monday, December 10, 2018 11:39 PM
> To: systemd-devel at lists.freedesktop.org
> Subject: EXT :Re: [systemd-devel] Systemd dependencies
>
> 10.12.2018 23:26, Boyce, Kevin P [US] (AS) пишет:
>> I seem to be struggling with what should be a very basic operation. I've seen similar questions posted to the list here and none of them are really adequate.
>>
>> I'm trying to prompt the user to ask a question as the system is coming up (so the system can configure it's network and other things based on a hostname the user enters).
>>
>> I have this part working using system-ask-password which is executed using a oneshot/idle service unit. However before the user can enter their response on the console the graphic display starts up. In the unit file I've tried all sorts of combinations of Requires, After, WantedBy, RequiredBy, etc. to make the graphical.target happen only after this script has completed its execution to no avail.
>
> Delaying graphical.target won't delay start of display manager.
> graphical.target already is ordered after display manager, delaying it further won't change anything.
>
> You need to delay actual service that starts graphical environment, display-manager.service or similar; which one depends on your distribution.
>
> At least if I understand your question correctly.
>
>>
>> Any help would be appreciated. I've thought of creating a new custom target and putting my service in it. Is there a way to force another target not to start until another target is completely finished?
>>
>> Just wondering why this sort of operation is so hard.
>>
>> Thanks,
>> Kevin
>>
>>
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
More information about the systemd-devel
mailing list