Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 522786 - sys-process/runit-2.1.2 version bump
Summary: sys-process/runit-2.1.2 version bump
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: William Hubbs
URL: http://skarnet.org/cgi-bin/archive.cg...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-14 16:03 UTC by Anthony Parsons
Modified: 2014-11-14 20:52 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Parsons 2014-09-14 16:03:29 UTC
Runit 2.1.2 was released 10th August; the announcement can be found in the URL field.

This release contains only minor bugfixes/additions, renaming the ebuild works.
Comment 1 William Hubbs gentoo-dev 2014-11-10 19:57:32 UTC
All,

Our runit ebuild does some things I would like to change with the
version bump, which will allow me to fix bug #354053 and bug #409469 by
making the runlevel setup user configurable and moving us to be more in
line with upstream's recommendations for how runit services should be
installed.

The first change is to move /etc/runit/runsvdir/all to /etc/sv, which is
the upstream recommended location for runit service directories [1].

Along this same line, /var/service should be /etc/service since we do
our best to comply with fhs where possible, and /etc is where the
default service directory should be in that case [2].

I have found ways to make these changes transparently.

That leaves me with one question about this version bump.

Upstream does document runlevels. However, they seem to recommend a
single flat service directory with all of the services to monitor.

Since The older runit ebuilds only set up one runlevel with getty's, it
seems sensible to use only a flat service directory on new installs and
to possibly recommend that everyone move to this setup.

Thoughts?

[1] http://www.smarden.org/runit/faq.html
[2] http://www.smarden.org/runit/upgrade.html
Comment 2 William Hubbs gentoo-dev 2014-11-10 20:22:10 UTC
Another good reason for moving to a single directory of services instead
of runlevels is that if people want to use runit as a supervisor for an
OpenRC system, it is best to have all of the sevices we are monitoring
in one directory.
Comment 3 SpanKY gentoo-dev 2014-11-11 03:11:44 UTC
the userbase for this pkg is small, so feel free to make changes to better align with upstream when it makes sense

wrt service levels, isn't it possible to support both ?  or at least, while the default might be to search one dir, can't you tweak knobs in the conf.d so that you can use whichever mode you want ?
Comment 4 Andrew Miller 2014-11-11 18:19:51 UTC
Hi,

I imagine some people will be compiling runit with dietlibc and USE="static", since upstream recommends this on its website, and other distributions ship with a statically linked /sbin/runit.

It might be a good idea to add the following to src_prepare():

# see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726008
[[ ${COMPILER} == "diet" ]] && use ppc && filter-flags "-mpowerpc-gpopt"
Comment 5 Andrew Miller 2014-11-11 18:42:34 UTC
Just to clarify the above,

I downloaded runit-2.1.2.tar.gz and grepped for power, eg:

find ./admin/runit-2.1.2/ -type f -print0 | xargs -0 grep 'power'

and didn't see anything about this ppc bug. I also looked at the changelog. I believe it's fixed in the Debian package, not in the source.
Comment 6 SpanKY gentoo-dev 2014-11-11 22:22:09 UTC
(In reply to Andrew M. from comment #4)

i don't think dietlibc is common at all -- there are plenty of better alternatives.  we also don't want to grow this kind of super specific cruft in ebuilds.
Comment 7 Andrew Miller 2014-11-12 05:22:46 UTC
(In reply to SpanKY from comment #6)

Perhaps you should contact upstream and ask them to stop recommending dietlibc.

William, can you give some thought as to whether IUSE  should be +static. As I mentioned above, other distributions I've used (Finnix and Void Linux) ship with a statically linked /sbin/runit; it seems sensible for PID1.
Comment 8 William Hubbs gentoo-dev 2014-11-13 19:08:18 UTC
Version 2.1.2 is now in portage, thanks for the report.
Comment 9 William Hubbs gentoo-dev 2014-11-13 19:28:10 UTC
(In reply to SpanKY from comment #3)
> wrt service levels, isn't it possible to support both ?  or at least, while
> the default might be to search one dir, can't you tweak knobs in the conf.d
> so that you can use whichever mode you want ?

I don't know what you mean by conf.d; there isn't one for runit.

The runlevels are controlled by how the services are linked. 

/etc/sv is like /etc/init.d in OpenRC; that is where the service directories go.

Whether you use runlevels or not is controlled by what /etc/service is. If it is a flat directory with symbolic links, runit starts and supervises all services linked into that directory.

If it is a link to another directory, that is how you set up runlevels [1].

[1] http://smarden.org/runit/runlevels.html
(In reply to Andrew M. from comment #4)
> I imagine some people will be compiling runit with dietlibc and
> USE="static", since upstream recommends this on its website, and other
> distributions ship with a statically linked /sbin/runit.
> 
> It might be a good idea to add the following to src_prepare():
> 
> # see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726008
> [[ ${COMPILER} == "diet" ]] && use ppc && filter-flags "-mpowerpc-gpopt"

I added the test, now I will add the comment after I finish with this bug.

(In reply to Andrew M. from comment #7)
> (In reply to SpanKY from comment #6)
> 
> Perhaps you should contact upstream and ask them to stop recommending
> dietlibc.
> 
> William, can you give some thought as to whether IUSE  should be +static. As
> I mentioned above, other distributions I've used (Finnix and Void Linux)
> ship with a statically linked /sbin/runit; it seems sensible for PID1.

I can give it some thought, sure. We don't do that for any of our other inits, but it may make some sense.
Comment 10 William Hubbs gentoo-dev 2014-11-13 20:30:39 UTC
With 2.1.2, the default method of setting up runlevels is the way
upstream seems to set things up initially, one service level with all
services.

However, if folks want to, feel free to open another bug and give me an
idea of what you would like if it is something different and we can go
from there. :-)
Comment 11 SpanKY gentoo-dev 2014-11-13 21:55:10 UTC
(In reply to Andrew M. from comment #7)

runit is not special and does not qualify for an exception to IUSE=+static
Comment 12 Timo Ollech 2014-11-14 20:51:55 UTC
I had to create a symlink from /bin/chpst to /usr/bin/chpst to make the gettys work, also /etc/sv/initctl/run didn't have the x bit set. Did this occur to anyone else or am I the only one?!?