supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Mike Buland <xagafinelle@gmail.com>, supervision@list.skarnet.org
Subject: Re: Per-user service managers
Date: Thu, 20 Oct 2011 12:16:56 -0700	[thread overview]
Message-ID: <87vcrja2xj.fsf@servo.finestructure.net> (raw)
In-Reply-To: <CAK2oqq+uaxhPMF11Nuf+bEzOX_9uuL_OedEE20c0SjZ5N=-5BA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On Thu, 20 Oct 2011 12:11:38 -0600, Mike Buland <xagafinelle@gmail.com> wrote:
> As for controlling the runsvdir processes, I've never had ocassion to stop
> them once their started.  My program does track all of them, and it has been
> my intention to shutdown the runsvdir process for a user when they are
> removed from the svusers group.  However, since runsvdir is designed to run
> forever and my intention was to provide reliable services for priveleged
> users,  I'm not sure the restarting users runsvdir processes is necesarry.
> That doesn't mean I wouldn't happily accept a patch that provides that
> feature.

I think control of the user runsvdir processes is just as important as
control of other long-running processes that you usually intend to have
run forever (cron or apache or whatever).  That's why the sv interface
exists, after all, even though you don't usually intend to ever stop
cron, for example.  Ultimately there's always a need.  Stop the user's
service when they are removed from the system is a relevant example, for
instance.

I like to have a separate runsvdir process per user (as your system has)
but then to also have system-level runsv control over those user
runsvdir processes.  That's why I opted to go for separate runsv
directories per user.  I can then use a simple script to construct and
tear down those runsv directories as needed, and then use sv as root to
control the user directories from a system level.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

  reply	other threads:[~2011-10-20 19:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-20 16:26 Mike Buland
2011-10-20 17:40 ` Jameson Graef Rollins
2011-10-20 18:11   ` Mike Buland
2011-10-20 19:16     ` Jameson Graef Rollins [this message]
2011-10-20 19:21       ` Mike Buland
2011-10-21 16:44       ` problem with mailing list and multipart/mime? Jameson Graef Rollins
2011-10-21 18:55         ` Uffe Jakobsen
2011-10-22  1:31         ` Alex Efros
2011-10-22  2:01           ` Jameson Graef Rollins
2011-10-22 10:43             ` Alex Efros
2011-10-22 11:47               ` Laurent Bercot
2011-10-22 19:43                 ` Jameson Graef Rollins
2011-10-22 19:49                   ` Jameson Graef Rollins
2012-03-10 16:34                   ` Laurent Bercot
2011-10-22 19:16             ` Jameson Graef Rollins
2011-10-22  7:24         ` Laurent Bercot

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=87vcrja2xj.fsf@servo.finestructure.net \
    --to=jrollins@finestructure.net \
    --cc=supervision@list.skarnet.org \
    --cc=xagafinelle@gmail.com \
    /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).