supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Kelly Dean <kelly@prtime.org>
To: Laurent Bercot <ska-supervision@skarnet.org>
Cc: supervision@list.skarnet.org
Subject: Re: s6 bites noob
Date: Fri, 01 Feb 2019 04:18:50 +0000	[thread overview]
Message-ID: <QUjXzxc8Kr6t2Kc2XfGBy4JjQpCvjmhV55OUnldveH8@local> (raw)
In-Reply-To: <emfe5ab1fd-53b6-4bac-80b7-89770125b667@elzian>


Thanks for the fix. Longrun works now, though oneshot still fails, this time with a different message:
s6-sudoc: fatal: connect to the s6-sudod server - check that you have appropriate permissions.

I guess that's related to my running all this (including svscan) as non-root. s6rc-oneshot-runner is running now, though.

Should I run it as root? But then you'll be able to erase a lot more than just the contents of my home dir. ;-)

I do prefer that my software recognize that I'm an idiot, and refuse to do dubious things unless I specify some --force option. I've been saved countless times by programs designed with users' mental frailty in mind, and bitten countless times by the opposite.

The doc for rc says its diff's view diverges from s6's view only when the service fails permanently. I suggest adding there that downing the service using svc instead of rc qualifies as a permanent failure from rc's point of view. I guess this also means that if rc is used, then svc isn't supposed to be part of the normal user interface.

In the docs, I see no way to ask svc whether a service is up, or ask svscanctl which services are up. But obviously rc must be able to ask, in order to do the diff. I also see no straightforward way to ask rc whether a particular service is up, other than
s6-rc -a list | grep "^servicename$"

If inotify were portable, would you still consider svscanctl -a to be the best design, or would you omit the -a option and auto-rescan when the scan directory changed?


  reply	other threads:[~2019-02-01  4:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 18:32 Kelly Dean
2019-01-31 18:46 ` Kelly Dean
2019-01-31 20:19 ` Laurent Bercot
2019-01-31 21:53   ` svscan --help Jonathan de Boyne Pollard
2019-02-01  0:36   ` s6 bites noob Laurent Bercot
2019-02-01  4:18     ` Kelly Dean [this message]
2019-02-01  5:27       ` Colin Booth
2019-02-01  5:29       ` Colin Booth
2019-02-03  8:53   ` Kelly Dean
2019-02-03 10:19     ` Laurent Bercot
2019-02-04  7:42       ` Kelly Dean
2019-02-04 13:52         ` Laurent Bercot
2019-02-05  9:26           ` Kelly Dean
2019-02-05 19:44             ` Laurent Bercot
2019-02-03 10:39     ` svscan and supervise Jonathan de Boyne Pollard

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=QUjXzxc8Kr6t2Kc2XfGBy4JjQpCvjmhV55OUnldveH8@local \
    --to=kelly@prtime.org \
    --cc=ska-supervision@skarnet.org \
    --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).