configurable path to ./supervise/

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/

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

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/

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

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/

[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/

[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/

[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!

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

[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/

[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