Service started at bootup Though empty down file created

Service started at bootup Though empty down file created

[sindhu krishnan]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Hi,
I have "A" service which should not start at bootup. It will be started by
other service(using  s6-svc -u ).
I have added the "A" service in s6 bundle and created the empty down file
in service directory to consider the service as down until it is started by
other service. But in my case, Though I have a empty down file in "A"
service directory, It is started at bootup.

I have taken the below as reference and implemented. Can you please let me
know, what is the problem here.

An optional, empty, regular file named down. If such a file exists, the
default state of the service is considered down, not up: s6-supervise will
not automatically start it until it receives a s6-svc -u command. If
no down file
exists, the default state of the service is up

Thanks.

Re: Service started at bootup Though empty down file created

[Colin Booth]

On Thu, Jan 28, 2021 at 09:50:28AM +0530, sindhu krishnan wrote:
> Hi,
> I have "A" service which should not start at bootup. It will be started by
> other service(using  s6-svc -u ).
> I have added the "A" service in s6 bundle and created the empty down file
> in service directory to consider the service as down until it is started by
> other service. But in my case, Though I have a empty down file in "A"
> service directory, It is started at bootup.
> 
> I have taken the below as reference and implemented. Can you please let me
> know, what is the problem here.
> 
> An optional, empty, regular file named down. If such a file exists, the
> default state of the service is considered down, not up: s6-supervise will
> not automatically start it until it receives a s6-svc -u command. If
> no down file
> exists, the default state of the service is up
> 
> Thanks.
There are a few things interacting that makes what you're seeing happen. 

In a pure s6 system (that is, no s6-rc) the down file behaves exactly as
documented and you'll get the intended behavior. In fact, s6-rc-init
uses the down file internally to protect services from immediate startup
when first triggering s6-svscan after populating the scan dir. However,
because of the internal use, user-placed down files are not suitable for
use with s6-rc managed services since s6-rc will place and clear down
files as necessary. I'm pretty sure this is the problem that you're
running into since it sounds like s6-rc is bringing the service up as
part of the bundle start.

The short-term solution here to get the behavior that you want is to
include service A in your s6-rc service set but remove it from any
bundles. That way s6-rc will still properly handle the placement and
scanning of it but will not trigger it accidentally.

The longer-term solution is to refactor your layout so that this service
triggering isn't necessary. Assuming you always want to start A after
you start B (the triggering service), you can have A take a dependency
on B. Assuming you leverage the notification system (either internally
in the B service or via s6-notifyoncheck), s6-rc will guarantee that B
is started _and ready_ before bringing A up. This is by far the
preferable route since it involves fewer leaky abstractions or awkward
plumbing through the management layer.


-- 
Colin Booth