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
