Re: configurable path to ./supervise/

Re: configurable path to ./supervise/

[Mike]

>
>
> On Fri, 18 Apr 2008, Gerrit Pape wrote:
>
>> On Fri, Apr 18, 2008 at 03:27:54PM -0400, Charlie Brady wrote:
>>> I think you need a script to prepare the directories and symlinks for
>>> you. I don't think we want runsv to be any more complicated.
>>
>> The symlinks can be dangling links pointing into an existing directory.
>
> The symlinks aren't dangling are they, if they point to an existing
> directory? Or did you really mean "into an existing directory" - i.e. the
> target directory of the symlink does not exist, but its containing
> directory does?
>

I just tested it, "into an existing directory" is right.

I created this service:

test
  supervise -> /var/run/sv-test
  run
  log
    supervise -> /var/run/sv-test-log
    run
    main -> /var/log/sv-test

I did not create the directories /var/run/sv-test or /var/run/sv-test-log,
runit did that for me.  I did create /var/log/sv-test, and set permissions
on it.

This works just fine, and is actually pretty cool.

Also, I tried this same thing with making test/log/supervise point to
/var/run/sv-test/log, it also worked.  makes it a little neater...

-- 
--Mike

Re: configurable path to ./supervise/

[Robin Bowes]

Mike wrote:
> 
> I just tested it, "into an existing directory" is right.
> 
> I created this service:
> 
> test
>   supervise -> /var/run/sv-test
>   run
>   log
>     supervise -> /var/run/sv-test-log
>     run
>     main -> /var/log/sv-test
> 
> I did not create the directories /var/run/sv-test or /var/run/sv-test-log,
> runit did that for me.  I did create /var/log/sv-test, and set permissions
> on it.
> 
> This works just fine, and is actually pretty cool.
> 
> Also, I tried this same thing with making test/log/supervise point to
> /var/run/sv-test/log, it also worked.  makes it a little neater...

OK, so let me get my head round this...

The aim is to keep config files in /etc, but state information 
(supervise) in /var/ somewhere (and logs in /var/log/ somewhere)

Assuming I have the following dirs already created:

/etc/sv
/var/run/sv
/var/log/sv

To create a new service "test" with a log, I can do this:

mkdir -p /etc/sv/test/log
mkdir -p /var/log/sv/test
ln -s ../../../var/run/sv/test /etc/sv/test/supervise
ln -s ../../../../var/run/sv/test/log/ /etc/sv/test/log/supervise
ln -s ../../../../var/log/sv/test /etc/sv/test/log/main

I use a generic log run file, so I can symlink that:

ln -s ../../scripts/generic-log-run /etc/sv/test/log/run

Then, create the service run file, and symlink /etc/sv/test into 
/var/service.

ln -s ../../etc/sv/test /var/service

Hey, cool - that works!

Nice one!

R.

Re: configurable path to ./supervise/

[Alex Efros]

Hi!

... and now how it was originally designed for daemontools:

> Assuming I have the following dirs already created:
>
> /etc/sv
> /var/run/sv
> /var/log/sv

/service

> To create a new service "test" with a log, I can do this:
>
> mkdir -p /etc/sv/test/log
> mkdir -p /var/log/sv/test
> ln -s ../../../var/run/sv/test /etc/sv/test/supervise
> ln -s ../../../../var/run/sv/test/log/ /etc/sv/test/log/supervise
> ln -s ../../../../var/log/sv/test /etc/sv/test/log/main

mkdir -p /service/test/log/main

> I use a generic log run file, so I can symlink that:
>
> ln -s ../../scripts/generic-log-run /etc/sv/test/log/run
>
> Then, create the service run file, and symlink /etc/sv/test into 
> /var/service.
>
> ln -s ../../etc/sv/test /var/service

no differences here

is we all doing something wrong when wanna split service into 3 parts?
it's hard for me to believe djb wasn't aware about /var/run/ and /var/log/. :)

-- 
			WBR, Alex.

Re: configurable path to ./supervise/

[Charlie Brady]

On Sat, 19 Apr 2008, Alex Efros wrote:

> is we all doing something wrong when wanna split service into 3 parts?
> it's hard for me to believe djb wasn't aware about /var/run/ and /var/log/. :)

http://www.merriam-webster.com/dictionary/iconoclast

Re: configurable path to ./supervise/

[Alex Efros]

Hi!

On Fri, Apr 18, 2008 at 06:21:27PM -0400, Charlie Brady wrote:
> http://www.merriam-webster.com/dictionary/iconoclast

Very informative. And who is iconoclast here? djb? me? you?
DJB is smart, and if he doesn't used /var/{log,run} and put everything in
same directory, I'd like to know his reasons. Or at least your
supposition about these reasons.
This has nothing with icon or iconoclast.

-- 
			WBR, Alex.

Re: configurable path to ./supervise/

[Mike]

> Hi!
>
> On Fri, Apr 18, 2008 at 06:21:27PM -0400, Charlie Brady wrote:
>> http://www.merriam-webster.com/dictionary/iconoclast
>
> Very informative. And who is iconoclast here? djb? me? you?
> DJB is smart, and if he doesn't used /var/{log,run} and put everything in
> same directory, I'd like to know his reasons. Or at least your
> supposition about these reasons.
> This has nothing with icon or iconoclast.
>
> --
> 			WBR, Alex.
>

"a person who attacks settled beliefs or institutions"
Iconoclast describes djb, I believe.  He is smart, but he has little
reguard for established practices, and rarely gives a reason.  There are
numerous examples of this.  In this case I imagine he just wanted to keep
all of the data together in one place.  If daemontools supports symlinks
at least half as well as runit then it would be possible to distribute the
data as one sees fit.  As it is, I'm sure that djb is/was aware of
/var/{log,run} but prefers his own "better" way of doing things, just like
/packages, just like /var/qmail structure, just like maildir.

I'm not saying his ways are bad, I'm saying that he has never really tried
to make his stuff fit into the existing structures and practices.  He
feels that his way is better, and should be used no matter what practices
predate them.

--Mike

Re: configurable path to ./supervise/

[Charlie Brady]

On Sat, 19 Apr 2008, Alex Efros wrote:

> On Fri, Apr 18, 2008 at 06:21:27PM -0400, Charlie Brady wrote:
>> http://www.merriam-webster.com/dictionary/iconoclast
>
> Very informative. And who is iconoclast here? djb? me? you?

djb is nothing if not iconoclastic.

> DJB is smart, and if he doesn't used /var/{log,run} and put everything in
> same directory, I'd like to know his reasons.

If he has written down his thoughts about those particular file location 
conventions, they might be here:

http://cr.yp.to/unix.html

Re: configurable path to ./supervise/

[Robin Bowes]

Alex Efros wrote:
> Hi!
> 
> ... and now how it was originally designed for daemontools:
> 
>> Assuming I have the following dirs already created:
>>
>> /etc/sv
>> /var/run/sv
>> /var/log/sv
> 
> /service

No. /service is equivalent to /var/service.

> 
>> To create a new service "test" with a log, I can do this:
>>
>> mkdir -p /etc/sv/test/log
>> mkdir -p /var/log/sv/test
>> ln -s ../../../var/run/sv/test /etc/sv/test/supervise
>> ln -s ../../../../var/run/sv/test/log/ /etc/sv/test/log/supervise
>> ln -s ../../../../var/log/sv/test /etc/sv/test/log/main
> 
> mkdir -p /service/test/log/main

No, you create the service elsewhere and symlink it to /service.

> 
>> I use a generic log run file, so I can symlink that:
>>
>> ln -s ../../scripts/generic-log-run /etc/sv/test/log/run
>>
>> Then, create the service run file, and symlink /etc/sv/test into 
>> /var/service.
>>
>> ln -s ../../etc/sv/test /var/service
> 
> no differences here
> 
> is we all doing something wrong when wanna split service into 3 parts?
> it's hard for me to believe djb wasn't aware about /var/run/ and /var/log/. :)

It's a different way of doing things.

To fit in with FHS, certain things should go in certain places. That's 
the reason to do it "my" way. I'm not arguing that it's better, or 
right, but this is the reason.

R.

/service vs /var/service vs /etc/service

[Gerrit Pape]

On Sat, Apr 19, 2008 at 12:39:11AM +0100, Robin Bowes wrote:
> It's a different way of doing things.
>
> To fit in with FHS, certain things should go in certain places. That's  
> the reason to do it "my" way. I'm not arguing that it's better, or  
> right, but this is the reason.

Hi, I'm in the same situation, Debian adheres strictly to the FHS.
Establishing /var/service apparently failed, runit in Debian used it
since 2002, it's runit's default since 2003.  But /var/service doesn't
comply with the FHS, and this will not change.

The Debian runit package now switched to /etc/service, and I'm about to
change runit to use /service by default, just as daemontools does.
daemontools in Debian, just like runit in Debian, uses /etc/service, and
recommends to create a compatibility symlink /service -> /etc/service.

To support putting the ./supervise/ directories into a different
location than the service directories, runit deals with dangling
symlinks as discussed.  For Debian I added the update-service(8) program
to help managing this, when using update-service(8) and sv(8) you don't
need to know about the location of the directory for services, /service,
/var/service, or /etc/service, and the symlinks are set up
automatically.  So servise directories managed with these tools comply
with the FHS.

I hope this will work out.

Regards, Gerrit.

Re: /service vs /var/service vs /etc/service

[Robin Bowes]

Gerrit Pape wrote:
> The Debian runit package now switched to /etc/service, and I'm about to
> change runit to use /service by default, just as daemontools does.
> daemontools in Debian, just like runit in Debian, uses /etc/service, and
> recommends to create a compatibility symlink /service -> /etc/service.

Out of interest, where do you/Debian/others put the actual service 
directories, i.e. containing the run file and log dir? I currently use 
/etc/sv/servicename and symlink to /var/service/

I guess I shall be symlinking to /service in future.

R.

Re: /service vs /var/service vs /etc/service

[Gerrit Pape]

On Sat, Apr 19, 2008 at 02:35:43PM +0100, Robin Bowes wrote:
> Gerrit Pape wrote:
>> The Debian runit package now switched to /etc/service, and I'm about to
>> change runit to use /service by default, just as daemontools does.
>> daemontools in Debian, just like runit in Debian, uses /etc/service, and
>> recommends to create a compatibility symlink /service -> /etc/service.
>
> Out of interest, where do you/Debian/others put the actual service  
> directories, i.e. containing the run file and log dir? I currently use  
> /etc/sv/servicename and symlink to /var/service/

Me/Debian: /etc/sv/<service-name>, and the ./supervise symlinks point to
/var/lib/supervise/<service-name>[.log].  /var/run/ turned out to not be
appropriate, since it might be cleaned up on reboot, losing permission
changes possibly made to the directory and files in it.

Regards, Gerrit.

Re: /service vs /var/service vs /etc/service

[Robin Bowes]

Gerrit Pape wrote:
> On Sat, Apr 19, 2008 at 02:35:43PM +0100, Robin Bowes wrote:
>> Gerrit Pape wrote:
>>> The Debian runit package now switched to /etc/service, and I'm about to
>>> change runit to use /service by default, just as daemontools does.
>>> daemontools in Debian, just like runit in Debian, uses /etc/service, and
>>> recommends to create a compatibility symlink /service -> /etc/service.
>> Out of interest, where do you/Debian/others put the actual service  
>> directories, i.e. containing the run file and log dir? I currently use  
>> /etc/sv/servicename and symlink to /var/service/
> 
> Me/Debian: /etc/sv/<service-name>, and the ./supervise symlinks point to
> /var/lib/supervise/<service-name>[.log].  /var/run/ turned out to not be
> appropriate, since it might be cleaned up on reboot, losing permission
> changes possibly made to the directory and files in it.

Thanks - that fits in with my gut feeling too (that /var/lib should be 
used rather than /var/run).

Where can I get the update-service script from? Would it be worth 
distributing that with runit?

R.

Re: /service vs /var/service vs /etc/service

[Gerrit Pape]

On Sat, Apr 19, 2008 at 03:13:18PM +0100, Robin Bowes wrote:
> Where can I get the update-service script from? Would it be worth  
> distributing that with runit?

I'm not sure.  It's in
 http://ftp.debian.org/debian/pool/main/r/runit/runit_1.8.0-7.diff.gz

Regards, Gerrit.

RE: /service vs /var/service vs /etc/service

[rehan khan]

Hi all,

A very interesting discussion. I came across similar issues. The
standardised linux filesystem causes some issues in layout for runit
services where more configurability would come in handy.

Some points I would like to throw out for discussion are:

1) Although I have not extensively tested it I think SE Linux doesn't
get so easily fooled by all this sym linking. An application constrained
by SE Linux will be denied access to areas it is not allowed to access
by policy. So runit sevices might need to have additional policy to
support this. Having the service directories in /etc/init.d/service/NAME
kind of works around this issue as the service directories inherit
init's SE Linux policy  after a relabel but this doesn't really fix all
the potential problems. However this actually works out quite well as
SysV init utilises scripts and runit utilises directories and so
everything can fit into init.d or rc.d without causing too much
confusion. Recently SE Linux has been adopted by more distros and this
could become a more pressing issue (not just for Red Hat/Centos/Fedora
where it is enabled by default).

2) 'Shared memory' (on fedora /dev/shm - a tmpfs filesystem) might be a
good place to store the supervise directories as they are usually small
in size. They would also get erased on a reboot which is not such a big
issue as runit will re-create them. This would also alleviate a small
amount of disk i/o (==thrashing) during start-up. Not a big issue for
servers I guess but more important for desktop/laptop systems where
restarting is more common (at least until suspend/resume works out of
the box for more machines). The log directories would of course have to
point to a normal file system. This has the same issue as /var/run as it
will definitely get cleaned out on a reboot so the run script will have
to ensure that permissions are set correctly (which it should be doing
anyway to be robust).

So based on the above I would suggest a possible layout as follows:

(configuration) - /etc/rc.d/SERVICE NAME or /etc/rc.d/service/SERVICE
NAME for the service directories (or init.d instead of rc.d).

(working files) - /dev/shm/supervised/SERVICENAME

(logs) - /var/log/Service/SERVICE NAME or /var/log/SERVICE NAME


A couple of other things that would be nice to have (but off topic):

1) To enable runit to mirror more closely sysv init scripts that start
multiple processes. For example the nfs init script on Fedora starts
three or four services which together provide nfs. To mirror this as a
runit managed service one could use the main runsv to run a second runsv
as a service which started the same services but in a grouping of their
own. Right now if the secondary runsv is stopped (using sv stop) it
orphans the services or sv proceses it was supervising instead of
stopping them. 

This could be implemented as a runsv switch which tells runsv to send a
down command to all the services being managed and to wait until they
have all exited (report back as down) before stopping the sv processes
themselves and exiting itself. Using this, quite sophisticated service
management can be implemented without having to have a bunch of
additional related but separate service directories and the runit scheme
would more closely resemble the init scripts in that distro.

Another example would be the init script for vsftpd. This script
dynamically creates processes for each configured ftp site. To mirror
this I have a script which dynamically creates a service directory for
each ftp site and then runs runsv to start them. Stopping runsv does not
stop the vsftpd processes but orphans them. Being able to have runsv
tear everything down (sensibly), after being sent a term and before
exiting would make this just work.

2) It seems quite fashionable to connect things to the D-bus these days
and I am wondering if runit can leverage some of d-bus' functionality to
advertise services to the system or respond to service startup requests
over d-bus or at least provide notification of start/stop events. Of
course runit would have to start the d-bus service first :) I think I
have mentioned this before and it was shot down as over-complicating
things but it's still on my wish list.

3) A post-start script that sv runs if service X has been up for n
number of seconds. This could be implemented as an option to sv (e.g sv
-postart or sv -postart=n), as a shell variable or if a poststart
executable file exisis in the service directory then sv can just run it
an n number of seconds after the service has started (or been up, like
it does if the finish script exists). Although the number of seconds
should be variable depending on the speed of the machine a sensible
default could be used. As the original shell has been replaced by
execing the service this would necessarily need to be run in it's own
shell but sv would not have to supervise it, just run it assuming that
the service has started successfully if it has been up for n number of
seconds. This would be really useful. In fact a poststart script would
negate the need for a d-bus interface as the d-bus stuff could just be
done in the poststart (announces it is up) and finish scripts (announces
it is down).


Of course these things would be better demonstrated if I could produce
some code but C is a mystery to me. If there is some interest I could
probably do something in Python as a proof of concept to see if these
suggestions might be useful in the real world.


Cheers
rehan



-----Original Message-----
From: Robin Bowes [mailto:robin-lists@robinbowes.com] 
Sent: 19 April 2008 15:16
To: supervision@list.skarnet.org
Subject: Re: /service vs /var/service vs /etc/service

Gerrit Pape wrote:
> On Sat, Apr 19, 2008 at 02:35:43PM +0100, Robin Bowes wrote:
>> Gerrit Pape wrote:
>>> The Debian runit package now switched to /etc/service, and I'm about
to
>>> change runit to use /service by default, just as daemontools does.
>>> daemontools in Debian, just like runit in Debian, uses /etc/service,
and
>>> recommends to create a compatibility symlink /service ->
/etc/service.
>> Out of interest, where do you/Debian/others put the actual service  
>> directories, i.e. containing the run file and log dir? I currently
use  
>> /etc/sv/servicename and symlink to /var/service/
> 
> Me/Debian: /etc/sv/<service-name>, and the ./supervise symlinks point
to
> /var/lib/supervise/<service-name>[.log].  /var/run/ turned out to not
be
> appropriate, since it might be cleaned up on reboot, losing permission
> changes possibly made to the directory and files in it.

Thanks - that fits in with my gut feeling too (that /var/lib should be 
used rather than /var/run).

Where can I get the update-service script from? Would it be worth 
distributing that with runit?

R.

configurable path to ./supervise/

[Alex Efros]

Hi!

I dislike idea to create ./supervise/ subdirectories in service's directory.
This violates idea with storing temporary files in /tmp/ or /var/run/...
and so make it non-trivial to prepare tar or patch for service.

Why not add feature to configure directory where `runsv` will create
./supervise/ and `sv` will look for it?

Something like:
    export SUPERVISE=/var/run/service
    exec runsvdir /var/service
and then `runsv` executed by `runsvdir` in directory /var/service/tinydns/
will see $SUPERVISE and create /var/run/service/tinydns/supervise/ and
/var/run/service/tinydns/log/supervise/.

Of course $SUPERVISE also should be set to same value to allow `sv` to
find ./supervise/ directories in /var/run/.

Another scheme - use hard-coded /var/service/.supervise/ directory, so
`runsv` executed by `runsvdir` in directory /var/service/tinydns/
will create /var/service/.supervise/tinydns/ and
/var/service/.supervise/tinydns/log/. Of course this behavior should be
optional and activated by some environment variable. Same variable point
`sv` where to find control directories.

Then I'll just make /var/service/.supervise/ symlink to /var/run/service/.

Currently I achieve this goal by making both ./supervise/ and
./log/supervise/ are symlinks to /var/run/service/NAME/supervise/ and 
/var/run/service/NAME/log/supervise/. But I always forget to prepare these
directories and symlinks BEFORE runsv will be started first time, and that
finally result in avoiding this idea and let runsv to do what it want.

Any thought?

-- 
			WBR, Alex.

Re: configurable path to ./supervise/

[Charlie Brady]

On Fri, 18 Apr 2008, Alex Efros wrote:

> I dislike idea to create ./supervise/ subdirectories in service's directory.
> This violates idea with storing temporary files in /tmp/ or /var/run/...
> and so make it non-trivial to prepare tar or patch for service.
>
> Why not add feature to configure directory where `runsv` will create
> ./supervise/ and `sv` will look for it?
...
> Any thought?

Use a symlink.

Re: configurable path to ./supervise/

[Alex Efros]

Hi!

On Fri, Apr 18, 2008 at 03:10:25PM -0400, Charlie Brady wrote:
> Use a symlink.

You skipped important part:

>> Currently I achieve this goal by making both ./supervise/ and
>> ./log/supervise/ are symlinks to /var/run/service/NAME/supervise/ and
>> /var/run/service/NAME/log/supervise/. But I always forget to prepare these
>> directories and symlinks BEFORE runsv will be started first time, and that
>> finally result in avoiding this idea and let runsv to do what it want.

-- 
			WBR, Alex.

Re: configurable path to ./supervise/

[Charlie Brady]

On Fri, 18 Apr 2008, Alex Efros wrote:

> On Fri, Apr 18, 2008 at 03:10:25PM -0400, Charlie Brady wrote:
>> Use a symlink.
>
> You skipped important part:

Sorry, I realised that as soon as I hit 'send'.

>>> Currently I achieve this goal by making both ./supervise/ and
>>> ./log/supervise/ are symlinks to /var/run/service/NAME/supervise/ and
>>> /var/run/service/NAME/log/supervise/. But I always forget to prepare these
>>> directories and symlinks BEFORE runsv will be started first time, and that
>>> finally result in avoiding this idea and let runsv to do what it want.

I think you need a script to prepare the directories and symlinks for you. 
I don't think we want runsv to be any more complicated.

Re: configurable path to ./supervise/

[Gerrit Pape]

On Fri, Apr 18, 2008 at 03:27:54PM -0400, Charlie Brady wrote:
> I think you need a script to prepare the directories and symlinks for 
> you. I don't think we want runsv to be any more complicated.

The symlinks can be dangling links pointing into an existing directory.
And such a script has been introduced into Debian recently ;)

 http://manpages.debian.net/cgi-bin/man.cgi?query=update-service

Regards, Gerrit.

Re: configurable path to ./supervise/

[Charlie Brady]

On Fri, 18 Apr 2008, Gerrit Pape wrote:

> On Fri, Apr 18, 2008 at 03:27:54PM -0400, Charlie Brady wrote:
>> I think you need a script to prepare the directories and symlinks for
>> you. I don't think we want runsv to be any more complicated.
>
> The symlinks can be dangling links pointing into an existing directory.

The symlinks aren't dangling are they, if they point to an existing 
directory? Or did you really mean "into an existing directory" - i.e. the 
target directory of the symlink does not exist, but its containing 
directory does?

Re: configurable path to ./supervise/

[Andras Korn]

On Fri, Apr 18, 2008 at 10:06:12PM +0300, Alex Efros wrote:

> Currently I achieve this goal by making both ./supervise/ and
> ./log/supervise/ are symlinks to /var/run/service/NAME/supervise/ and 
> /var/run/service/NAME/log/supervise/. But I always forget to prepare these
> directories and symlinks BEFORE runsv will be started first time, and that
> finally result in avoiding this idea and let runsv to do what it want.
> 
> Any thought?

If only the last directory component is missing, runsv creates it on
startup.

So point your symlinks to /var/run/NAME-supervise and
/var/run/NAME-log-supervise or similar.

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
          The Moon is covered with the results of astronomical odds.