On Oct 20, 2011 11:40 AM, "Jameson Graef Rollins" <
jrollins@finestructure.net> wrote:
>
> On Thu, 20 Oct 2011 10:26:17 -0600, Mike Buland <xagafinelle@gmail.com>
wrote:
> > I wrote this little program that manages per-user runsv instances.
> > For each user in the "svusers" group it starts a service manager in
> > their ~/.sv directory.  The service manager runs as that user, so as
> > long as they can run the sv program, they can manage their own
> > services.
> >
> > Per-user service managers run independently of user logins.
> >
> > I've released this under the BSD license, and it's available on github.
> >
> > https://github.com/eichlan/usersv
>
> Hey, Mike.  Very cool!  I actually wrote basically the exact same thing
> a while ago, but never got around to publishing it.  I think this sort
> of thing can be very useful.  Thanks for sharing.
>
> I see that your system uses a single process that spawns a runsvdir for
> each user.  The problem I see with that is that it's hard to
> individually control the user runsvdir processes.  If you do have an
> idea about how to control (ie. start/stop/restart/etc.) the user
> runsvdir processes I would be interested in hearing it.

If I understand correctly you're referring to the directory containing the
services.  This program uses the .sv directory in each user's home
directory.

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 that's actually an interesting question, my original idea was based
around a grant/revoke model.  Providing more fine grain control of the
users' service managers never occured to me.

Thank you for your reply, it's always good to get feedback.

> The system I put together uses a separate runsv dir for each user, and
> the entire system is basically encapsulated in the runsv run script (and
> log/run script), which I've pasted in below.  The env dir for this
> particular example is as follows:
>
> HOME=/home/jrollins
> LOG=/home/jrollins/.service.log
> PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
> RUNSVDIR=/home/jrollins/.service
> USER=jrollins
>
> Anyway, just thought you might be interested, and thanks again for
> sharing your work.
>
> jamie.
>
>
> servo 0$ cat /etc/sv/runsvdir-jrollins/run
> #!/bin/sh
> exec 2>&1
> USER=`head env/USER`
> RUNSVDIR=`head env/RUNSVDIR`
> GROUPS=$(groups "$USER" | cut -d: -f2 | tr ' ' ':')
> echo "${USER}${GROUPS}"
> until [ -d "$RUNSVDIR" ] ; do
>    sleep 10
> done
> if [ -d log/main ] ; then
>    exec chpst -u "${USER}${GROUPS}" -e env \
>        runsvdir -P "$RUNSVDIR"
> else
>    exec chpst -u "${USER}${GROUPS}" -e env \
>        runsvdir -P "$RUNSVDIR" 'log:
...........................................................................................................................................................................................................................................................................................................................................................................................................'
> fi
>
> servo 0$ cat /etc/sv/runsvdir-jrollins/log/run
> #!/bin/sh
> set -e
> LOG=`readlink -f ./main`
> USER=`head ../env/USER`
> if ! [ -d "$LOG" ] ; then
>    mkdir -p -m0750 "$LOG"
>    chown "$USER":"$USER" "$LOG"
> fi
> exec chpst -u "$USER" svlogd -tt "$LOG"