Systemd service life cycle

[Tom H]

On Thu, Apr 7, 2016 at 2:38 PM, Colin Law <clanlaw at gmail.com> wrote:
> On 7 April 2016 at 12:04, Tom H <tomh0665 at gmail.com> wrote:
>> On Thu, Apr 7, 2016 at 9:43 AM, Colin Law <clanlaw at gmail.com> wrote:
>>> On 6 April 2016 at 22:33, Tom H <tomh0665 at gmail.com> wrote:
>>>> On Wed, Apr 6, 2016 at 11:01 PM, Colin Law <clanlaw at gmail.com> wrote:
>>>>>
>>>>> I am trying to define the startup order of a couple of systemd
>>>>> services. I see in the docs how I can use After, Before etc to
>>>>> control the order. What is not clear to me is at exactly what point
>>>>> in the startup of a service it becomes "Started", thereby allowing the
>>>>> next service to be started.
>>>>
>>>> If B has "Requires=A" and "After=A", it'll start after A has been started.
>>>
>>> Thanks Tom, I had managed to glean that much from the docs. The
>>> question is, though, what is meant by "Started"? I have an operation
>>> performed by A that I need to be completed before B is started (I am
>>> setting up an ssh tunnel to a server that B uses).
>>
>> AFAIK
>>
>> 1) 'B has "Requires=A" and "After=A"' means that means that B starts
>> after A is up and running not just started.
>
> What is the difference, in the case of a service of Type=simple,
> between A being started and being up and running. How long should be
> the delay between starting the process and deciding it is up and
> running?

I'm sorry. I forgot about types!

For "simple", units that are ordered after it are started when it's started.

For "forking", units are ordered after it are started when it's
started but it's considered started when the parent process exits.

For "oneshot", units are ordered after it are started when it exits.


>> 2) There's one case where this isn't as intuitive and that's
>> networking. systemd decided to make network.target correspond to the
>> LSB $network "system facility" and that facility corresponds to
>> networking being brought up and not actually being up. So
>> network-online.target came to be.
>>
>>> Currently I do that first thing in the script invoked by ExecStart but
>>> sometimes B is started before the tunnel is up. This leads me to think
>>> that A is defined as Started once ExecStart has been called, but only
>>> guarantees that the script has been initiated, not that it has
>>> actually accomplished anything. If I am correct then I think I should
>>> put the tunnel setup in ExecStartPre.
>>
>> I don't think that ExecStartPre is the right place setting up the
>> tunnel because it shouldn't be used for a long-running process; it's
>> meant for a setup for ExecStart.
>>
>> Are you saying that
>>
>> 1) A sets up a tunnel
>>
>> 2) B needs that tunnel to be up and has 'Requires=A" and "After=A" but
>> sometimes the tunnel isn't set up when B needs it?
>
> Yes, but I think I understand the reason now. It is because I have
> set Type=simple for A, which means that systemd starts the process (A)
> and immediately declares it as Started. The process is running, but
> it may take large fractions of a second to setup the tunnel across the
> internet.

"oneshot" is better for your use-case. I forgot...