FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-20-2011, 05:24 PM
William Hubbs
 
Default rfc: openrc use flag

All,

This bug [1] brings up an issue that I would like thoughts about.

sys-fs/udev and net-wireless/bluez, among other packages, install udev
rules which assume that you are using openrc.

On systems where openrc is not used in the boot process, this causes
issues because openrc services are run by the udev rules even though
openrc did not boot the system.

The author of the bug feels that the way to fix this is for us to put a
check in openrc that makes it refuse to run services if it was not used
in the boot process.

This may work; however, I do not feel that it addresses the root cause
of the bug. I feel that the root cause is packages unconditionally
installing udev rules which assume everyone uses openrc.

My proposal is to give these packages an "openrc" use flag which will
control whether or not openrc specific support will be installed. This
would be on by default, of course, since most of us use openrc.

The author of the bug is correct about the disadvantage of doing this --
if you want to switch on or off openrc support, this will require a
rebuild of the affected packages.

I feel that the advantage of this approach outweighs this disadvantage
because this approach allows the user to tell udev not to even attempt
to run openrc services, and this will lead to a more efficient system.

Any input would be appreciated.

William

[1] http://bugs.gentoo.org/show_bug.cgi?id=364159
 
Old 04-20-2011, 06:02 PM
Peter Volkov
 
Default rfc: openrc use flag

В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> The author of the bug feels that the way to fix this is for us to put a
> check in openrc that makes it refuse to run services if it was not used
> in the boot process.

This is good idea to have in any case since I remember my system went
crazy after I've tried to start some service inside chroot.

> This may work; however, I do not feel that it addresses the root cause
> of the bug. I feel that the root cause is packages unconditionally
> installing udev rules which assume everyone uses openrc.

I'd voted to have both implemented.

--
Peter.
 
Old 04-20-2011, 06:20 PM
Pacho Ramos
 
Default rfc: openrc use flag

El mié, 20-04-2011 a las 22:02 +0400, Peter Volkov escribió:
> В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > The author of the bug feels that the way to fix this is for us to put a
> > check in openrc that makes it refuse to run services if it was not used
> > in the boot process.
>
> This is good idea to have in any case since I remember my system went
> crazy after I've tried to start some service inside chroot.
>
> > This may work; however, I do not feel that it addresses the root cause
> > of the bug. I feel that the root cause is packages unconditionally
> > installing udev rules which assume everyone uses openrc.
>
> I'd voted to have both implemented.
>

I would vote for the first one, I still don't like "openrc" USE flag
approach much because:
1. Would need to rebuild some packages when switching between init
systems.
2. I remember (from "logrotate" USE flag case) that using an USE flag
for simply installing or not a file is not usually preferred :-/

Best regards
 
Old 04-20-2011, 06:22 PM
William Hubbs
 
Default rfc: openrc use flag

On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > The author of the bug feels that the way to fix this is for us to put a
> > check in openrc that makes it refuse to run services if it was not used
> > in the boot process.
>
> This is good idea to have in any case since I remember my system went
> crazy after I've tried to start some service inside chroot.

My concern about it though is prefix installs. If I implement something
like this, will it not break openrc on prefix systems?

William
 
Old 04-20-2011, 06:33 PM
Michał Górny
 
Default rfc: openrc use flag

On Wed, 20 Apr 2011 13:22:53 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > > The author of the bug feels that the way to fix this is for us to
> > > put a check in openrc that makes it refuse to run services if it
> > > was not used in the boot process.
> >
> > This is good idea to have in any case since I remember my system
> > went crazy after I've tried to start some service inside chroot.
>
> My concern about it though is prefix installs. If I implement
> something like this, will it not break openrc on prefix systems?

I'm attaching the patch I suggested to fix the issue.

It is based on the assumption that in order to run cleanly, OpenRC
needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark all services
stopped). It assumes that the basic effect of a running OpenRC
is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.

I tested that approach with clean OpenRC and systemd installs, and it
doesn't create any issues. I'd appreciate if someone with Prefix system
could test it as well.


--
Best regards,
Michał Górny
 
Old 04-20-2011, 06:44 PM
Fabian Groffen
 
Default rfc: openrc use flag

On 20-04-2011 13:22:53 -0500, William Hubbs wrote:
> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > > The author of the bug feels that the way to fix this is for us to put a
> > > check in openrc that makes it refuse to run services if it was not used
> > > in the boot process.
> >
> > This is good idea to have in any case since I remember my system went
> > crazy after I've tried to start some service inside chroot.
>
> My concern about it though is prefix installs. If I implement something
> like this, will it not break openrc on prefix systems?

does such thing exist?


--
Fabian Groffen
Gentoo on a different level
 
Old 04-21-2011, 02:31 AM
Jeroen Roovers
 
Default rfc: openrc use flag

On Wed, 20 Apr 2011 22:02:41 +0400
Peter Volkov <pva@gentoo.org> wrote:

> В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > The author of the bug feels that the way to fix this is for us to
> > put a check in openrc that makes it refuse to run services if it
> > was not used in the boot process.

Why refuse? It could instead assume it needed to only start a service
in, say, a chroot, like ssh or apache2, without assuming anything else
needs to be done. If the service needed anything else, it could be
left to fail on its own terms.

> This is good idea to have in any case since I remember my system went
> crazy after I've tried to start some service inside chroot.

Basically, baselayout/openrc (baselayout-1 has the same problem) would
(try to) shut down your system because it thought something was
terribly wrong. That's bitten me as well when I still thought I could
test services inside a chroot.

> > This may work; however, I do not feel that it addresses the root
> > cause of the bug. I feel that the root cause is packages
> > unconditionally installing udev rules which assume everyone uses
> > openrc.

How should the udev rules be changed to match /any/ init system?


jer
 
Old 04-21-2011, 04:34 AM
William Hubbs
 
Default rfc: openrc use flag

On Thu, Apr 21, 2011 at 04:31:46AM +0200, Jeroen Roovers wrote:
> On Wed, 20 Apr 2011 22:02:41 +0400
> Peter Volkov <pva@gentoo.org> wrote:
>
> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > > The author of the bug feels that the way to fix this is for us to
> > > put a check in openrc that makes it refuse to run services if it
> > > was not used in the boot process.
>
> Why refuse? It could instead assume it needed to only start a service
> in, say, a chroot, like ssh or apache2, without assuming anything else
> needs to be done. If the service needed anything else, it could be
> left to fail on its own terms.

This might be possible; I would just change the message in the patch
provided to something like,

"Warning, openrc did not boot this system, so you may get unpredictable results.
"

> > This is good idea to have in any case since I remember my system went
> > crazy after I've tried to start some service inside chroot.
>
> Basically, baselayout/openrc (baselayout-1 has the same problem) would
> (try to) shut down your system because it thought something was
> terribly wrong. That's bitten me as well when I still thought I could
> test services inside a chroot.
>
> > > This may work; however, I do not feel that it addresses the root
> > > cause of the bug. I feel that the root cause is packages
> > > unconditionally installing udev rules which assume everyone uses
> > > openrc.
>
> How should the udev rules be changed to match /any/ init system?

For an example of the problem, take a look on your system at
/lib/udev/rules.d/90-network.rules. This is part of openrc's hotplug
functionality. Basically it tries to run
/etc/init.d/net.$INTERFACE start when a network interface is added to
the system and rc_hotplug allows it.

In net-wireless/bluez, you will see similar integration between openrc
and udev. Once bluez is installed, /lib/udev/rules.d/70-bluetooth.rules
runs bluetooth.sh which tries to run a service in /etc/init.d.

To make things work with /any/ init system, the best way to go would be
to make it a practice not to run services from within udev rules or
external run scripts like net.sh and bluetooth.sh in /lib/udev.

William
 
Old 04-21-2011, 04:52 AM
Duncan
 
Default rfc: openrc use flag

Michał Górny posted on Wed, 20 Apr 2011 20:33:27 +0200 as excerpted:

> On Wed, 20 Apr 2011 13:22:53 -0500 William Hubbs <williamh@gentoo.org>
> wrote:
>
>> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
>> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
>> > > The author of the bug feels that the way to fix this is for us to
>> > > put a check in openrc that makes it refuse to run services if it
>> > > was not used in the boot process.
>> >
>> > This is good idea to have in any case since I remember my system went
>> > crazy after I've tried to start some service inside chroot.
>>
>> My concern about it though is prefix installs.
>
> [The attached patch] is based on the assumption that in order to run
> cleanly, OpenRC needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark
> all services stopped). It assumes that the basic effect of a running
> OpenRC is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.
>
> I tested that approach with clean OpenRC and systemd installs, and it
> doesn't create any issues. I'd appreciate if someone with Prefix system
> could test it as well.

> http://bugs.gentoo.org/show_bug.cgi?id=364159.

The patch seems reasonable, but I can't but think that there's likely
corner-cases that may be unknown ATM that could complicate things. If we
establish a slightly broader base now, it can be reasonably expanded in
the future.

What about handling this much the same as subsystem-type auto-detection
was ultimately handled, but controlling how much of openrc should run:

1) Auto: (like rc_sys being commented out). This would do the auto-detect
thing using something like the suggested softlevel file detection patch.

2) On: Openrc is locked ON, and will try to handle everything. This
could be the default (much like rc_sys="").

3) Off: Openrc is locked OFF, and will immediately terminate as soon as it
loads the config far enough to see that it is OFF, if anything attempts to
run it.

4) Later? Nodep: (Target stable-next?) If the setting is "nodep", openrc
should assume all deps are met and simply run the script it is asked to
run, only.

5) Optionally, service.allowed: (Target bluesky?) Another setting could
list specific services that openrc should be allowed to run. If
service.allowed isn't empty/unset, anything not listed would not be run.
Nodep mode would be altered slightly by this, in that any listed service
could be depended normally, while anything not listed would be assumed to
be dependency-met. Normal (auto/on) mode would work in the reverse for
anything not listed. Since openrc isn't allowed to touch those services
but is operating in normal dependency mode, to openrc they'd not exist and
therefore block the start of any depending services as well.

6) Optionally, service.provided: To go along with #5, for openrc in normal
mode, it could borrow the "package.provided" concept from portage, making
it "service.provided". For normal mode, services listed in this third
setting, but ONLY these services, would be assumed to be met much as if
openrc was operating in nodeps mode. Services not in this list would be
treated as above. (This would allow openrc to nodep on services in
service.provided, while failing OTHER deps not found in service.allowed,
if service.allowed isn't empty/unset.

7) Optionally, service.blacklisted. This would be the negative version of
#5. Presumably, if both service.allowed AND service.blacklisted are set
and non-empty, one would take precedence and the other would be ignored
(with documentation as to which was which).

Obviously #5-7 are wish-list, not really appropriate for our current
target-stable. However, *if* they were thought sufficiently useful to
code up, these features could appear with a later version.

At least #1-3 should be quite easy to code and appropriate for stable,
since the config concept and implementation has already been tested to
some degree with the current but quite new subsystem-type implementation.

#4 falls in the middle. I threw it in based on jer's suggestion, which
I'd like to see even if #5-7 aren't implemented, but it's a big enough
feature-add that it really should have additional testing. As such I don't
see it for current-stable-target, but perhaps stable-next?

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 04-21-2011, 07:05 PM
William Hubbs
 
Default rfc: openrc use flag

On Wed, Apr 20, 2011 at 11:34:59PM -0500, William Hubbs wrote:
> On Thu, Apr 21, 2011 at 04:31:46AM +0200, Jeroen Roovers wrote:
> > How should the udev rules be changed to match /any/ init system?
>
> For an example of the problem, take a look on your system at
> /lib/udev/rules.d/90-network.rules. This is part of openrc's hotplug
> functionality. Basically it tries to run
> /etc/init.d/net.$INTERFACE start when a network interface is added to
> the system and rc_hotplug allows it.
>
> In net-wireless/bluez, you will see similar integration between openrc
> and udev. Once bluez is installed, /lib/udev/rules.d/70-bluetooth.rules
> runs bluetooth.sh which tries to run a service in /etc/init.d.
>
> To make things work with /any/ init system, the best way to go would be
> to make it a practice not to run services from within udev rules or
> external run scripts like net.sh and bluetooth.sh in /lib/udev.

Another option for this would be to include this level of udev
integration in the openrc package itself instead of spreading it through
the other packages.

If I do that, when you install openrc, you would optionally get those
pieces that integrate it with udev instead of those pieces coming from
the individual packages.

Comments?

William
 

Thread Tools




All times are GMT. The time now is 06:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org