From: Colin Booth <colin@heliocat.net>
To: supervision@list.skarnet.org
Subject: Re: Service started at bootup Though empty down file created
Date: Thu, 28 Jan 2021 05:13:22 +0000 [thread overview]
Message-ID: <20210128051322.GA28923@cathexis.xen.prgmr.com> (raw)
In-Reply-To: <CAAJ7f9Dbc-hKHXtUWUq5==xzQbemHeJJx7t+vvKQUVZVETWdFw@mail.gmail.com>
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
prev parent reply other threads:[~2021-01-28 5:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 4:20 sindhu krishnan
2021-01-28 5:13 ` Colin Booth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210128051322.GA28923@cathexis.xen.prgmr.com \
--to=colin@heliocat.net \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).