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
Received on Thu Jan 28 2021 - 05:13:22 UTC