runit-1.9.0 available

runit-1.9.0 available

[Gerrit Pape]

Hi, runit version 1.9.0 is available for testing

 http://smarden.org/runit/

The default directory for services is now /service/, and no longer
/var/service/.  To be consistent with the new default location, create a
symbolic link when upgrading
 # ln -s /var/service /

When installing runit on a system that should comply with the Filesystem
Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be
chosen, but /etc/service/.  It is recommended to create a compatibility
symlink /service pointing to /etc/service in this case.

This version additionally fixes the runsv program to properly handle
service directories with ./log being a symlink to a directory on a
different device, and slightly updates the sv program and the
documentation.

If you use runit regularly, please contribute[0] to the project.

Thanks, Gerrit.

Re: runit-1.9.0 available

[Robin Bowes]

Gerrit Pape wrote:

> When installing runit on a system that should comply with the Filesystem
> Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be
> chosen, but /etc/service/.  It is recommended to create a compatibility
> symlink /service pointing to /etc/service in this case.

Is this for the actual service configurations, or the directory 
monitored by runsvdir-start ?

Are you sure this is FHS-compliant? Wouldn't /var/run/service be a 
better location?

R.

Re: runit-1.9.0 available

[Gerrit Pape]

Robin Bowes <robin-lists <at> robinbowes.com> writes:
> Gerrit Pape wrote:
> > When installing runit on a system that should comply with the Filesystem
> > Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be
> > chosen, but /etc/service/.  It is recommended to create a compatibility
> > symlink /service pointing to /etc/service in this case.
> 
> Is this for the actual service configurations, or the directory 
> monitored by runsvdir-start ?

The latter.

> Are you sure this is FHS-compliant? Wouldn't /var/run/service be a 
> better location?

At Debian, which adheres to the FHS, we agreed that /etc/service/
doesn't conflict with the FHS, so yes.  /var/run/service is not
suitable, because /var/run/ may well be a ramdisk, and its content
is not guaranteed to survive a reboot.

Regards, Gerrit.

http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION

Re: runit-1.9.0 available

[George Georgalis]

On Tue 13 May 2008 at 10:48:59 AM +0000, Gerrit Pape wrote:
>Robin Bowes <robin-lists <at> robinbowes.com> writes:
>> Gerrit Pape wrote:
>> > When installing runit on a system that should comply with the Filesystem
>> > Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be
>> > chosen, but /etc/service/.  It is recommended to create a compatibility
>> > symlink /service pointing to /etc/service in this case.
>> 
>> Is this for the actual service configurations, or the directory 
>> monitored by runsvdir-start ?
>
>The latter.

Why not /etc/service as a default for all systems?

(as I speculate it's related to /etc/opt : Configuration files for /opt)

// George

>http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION


-- 
George Georgalis, information system scientist <IXOYE><

Re: runit-1.9.0 available

[Charles Duffy]

George Georgalis wrote:
> On Tue 13 May 2008 at 10:48:59 AM +0000, Gerrit Pape wrote:
>> Robin Bowes <robin-lists <at> robinbowes.com> writes:
>>> Gerrit Pape wrote:
>>>> When installing runit on a system that should comply with the Filesystem
>>>> Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be
>>>> chosen, but /etc/service/.  It is recommended to create a compatibility
>>>> symlink /service pointing to /etc/service in this case.
>>> Is this for the actual service configurations, or the directory 
>>> monitored by runsvdir-start ?
>> The latter.
> 
> Why not /etc/service as a default for all systems?
> 
> (as I speculate it's related to /etc/opt : Configuration files for /opt)

I've built netbooting/embedded systems where /etc was mounted read-only. 
Putting the run, check, supervise and finish scripts there makes sense 
-- but it would be nice if the supervise directories could be split out 
and stored elsewhere (presumably on tmpfs) in such environments.

Re: runit-1.9.0 available

[Zachary Kotlarek]

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


On May 15, 2008, at 12:10 PM, Charles Duffy wrote:

> George Georgalis wrote:
>> On Tue 13 May 2008 at 10:48:59 AM +0000, Gerrit Pape wrote:
>>> Robin Bowes <robin-lists <at> robinbowes.com> writes:
>>>> Gerrit Pape wrote:
>>>>> When installing runit on a system that should comply with the  
>>>>> Filesystem
>>>>> Hierarchy Standard (FHS), neither /service/ nor /var/service/  
>>>>> should be
>>>>> chosen, but /etc/service/.  It is recommended to create a  
>>>>> compatibility
>>>>> symlink /service pointing to /etc/service in this case.
>>>> Is this for the actual service configurations, or the directory  
>>>> monitored by runsvdir-start ?
>>> The latter.
>> Why not /etc/service as a default for all systems?
>> (as I speculate it's related to /etc/opt : Configuration files for / 
>> opt)
>
> I've built netbooting/embedded systems where /etc was mounted read- 
> only. Putting the run, check, supervise and finish scripts there  
> makes sense -- but it would be nice if the supervise directories  
> could be split out and stored elsewhere (presumably on tmpfs) in  
> such environments.

I do that exactly -- /, including /etc, is read-only on most of my  
systems. I put scripts in /etc/supervise so they hit the configuration  
management, and symlink the supervise directory to /var/tmp/run/ 
whatever so it can be read/write.

	Zach

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1919 bytes --]

Re: runit-1.9.0 available

[Robin Bowes]

Zachary Kotlarek wrote:

>> I've built netbooting/embedded systems where /etc was mounted 
>> read-only. Putting the run, check, supervise and finish scripts there 
>> makes sense -- but it would be nice if the supervise directories could 
>> be split out and stored elsewhere (presumably on tmpfs) in such 
>> environments.
> 
> I do that exactly -- /, including /etc, is read-only on most of my 
> systems. I put scripts in /etc/supervise so they hit the configuration 
> management, and symlink the supervise directory to /var/tmp/run/whatever 
> so it can be read/write.

That makes sense to me.

What would make more sense is being able to specify that the supervise 
directory should be created in some location other than the service 
directory, e.g. /var/run/service_name.

R.

Re: runit-1.9.0 available

[Radek Podgorny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/me likes this idea, too...

Radek P.


Robin Bowes wrote:
| Zachary Kotlarek wrote:
|
|>> I've built netbooting/embedded systems where /etc was mounted
|>> read-only. Putting the run, check, supervise and finish scripts there
|>> makes sense -- but it would be nice if the supervise directories
|>> could be split out and stored elsewhere (presumably on tmpfs) in such
|>> environments.
|>
|> I do that exactly -- /, including /etc, is read-only on most of my
|> systems. I put scripts in /etc/supervise so they hit the configuration
|> management, and symlink the supervise directory to
|> /var/tmp/run/whatever so it can be read/write.
|
| That makes sense to me.
|
| What would make more sense is being able to specify that the supervise
| directory should be created in some location other than the service
| directory, e.g. /var/run/service_name.
|
| R.
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgtjgsACgkQ7mej6pjlbYRaYACdFcp8LMNYIocJxbO9ouRViW8e
LIsAoKw2luyluv+iJQPtvl7DMar8czFE
=lyiI
-----END PGP SIGNATURE-----

Re: runit-1.9.0 available

[Charles Duffy]

Charles Duffy wrote:
> I've built netbooting/embedded systems where /etc was mounted read-only. 
> Putting the run, check, supervise and finish scripts there makes sense 

s/supervise/control/ on that last line.