supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
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

      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).