Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 468736 - sys-apps/openrc - RC_DEFAULTLEVEL variable has incorrect value if default runlevel is not default or softlevel is specified on the kernel command line
Summary: sys-apps/openrc - RC_DEFAULTLEVEL variable has incorrect value if default run...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-06 08:26 UTC by Max Hacking
Modified: 2013-05-08 09:16 UTC (History)
0 users

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


Attachments
Patch to resolve incorrect RC_DEFAULTLEVEL values (openrc-0.11.8-default_runlevel.patch,2.67 KB, text/plain)
2013-05-06 08:26 UTC, Max Hacking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Max Hacking 2013-05-06 08:26:06 UTC
Created attachment 347498 [details]
Patch to resolve incorrect RC_DEFAULTLEVEL values

Pretty much as the summary says...

When executing plugins OpenRC sets the RC_DEFAULTLEVEL environment variable to the value of the softlevel (or rc_runlevel) kernel command line parameter, which is clearly incorrect as this is *not* the default runlevel.

If neither of these parameters is specified then OpenRC sets the RC_DEFAULTLEVEL environment variable to "default" which may or may not be the default runlevel as configured in inittab.

The attached patch resolves these issues by:

1) Adding a new environment variable named RC_KRUNLEVEL which will contain the softlevel (or rc_runlevel) kernel command line parameter when supplied.

2) Replacing hard-coded "default" with a lookup from the inittab file (falling back to "default" should inittab be unparsable for some reason).

This patch should apply cleanly to most recent versions although the line numbers assume that the patch I supplied in bug 467368 has already been applied.
Comment 1 William Hubbs gentoo-dev 2013-05-06 16:33:38 UTC
(In reply to comment #0)
> 1) Adding a new environment variable named RC_KRUNLEVEL which will contain
> the softlevel (or rc_runlevel) kernel command line parameter when supplied.

We have an RC_RUNLEVEL environment variable, so I'm not sure why we need the RC_KRUNLEVEL variable. Does RC_RUNLEVEL have the correct value?

> 2) Replacing hard-coded "default" with a lookup from the inittab file
> (falling back to "default" should inittab be unparsable for some reason).

OpenRC is not written to be sysvinit specific, so we should not try to look up runlevels in inittab.

Also, the patch does not update the runscript man page with documentation about the RC_KRUNLEVEL environment variable.

This bug does bring up an interesting question. if we can't determine RC_DEFAULTLEVEL in a generic way, should we consider dropping it?
Comment 2 Max Hacking 2013-05-06 18:03:32 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > 1) Adding a new environment variable named RC_KRUNLEVEL which will contain
> > the softlevel (or rc_runlevel) kernel command line parameter when supplied.
> 
> We have an RC_RUNLEVEL environment variable, so I'm not sure why we need the
> RC_KRUNLEVEL variable. Does RC_RUNLEVEL have the correct value?

RC_RUNLEVEL contains the runlevel the script/plugin is currently being run from.
RC_KRUNLEVEL contains the runlevel specified using softinit or rc_runlevel on the kernel command line (or is undefined).
RC_DEFAULTLEVEL should contain the runlevel which will boot if nothing is specified on the kernel command line.

> > 2) Replacing hard-coded "default" with a lookup from the inittab file
> > (falling back to "default" should inittab be unparsable for some reason).
> 
> OpenRC is not written to be sysvinit specific, so we should not try to look
> up runlevels in inittab.

Hence the fallback to "default" if inittab is unreadable or does not exist.  As far as I know there is no other way of knowing the default runlevel.

> Also, the patch does not update the runscript man page with documentation
> about the RC_KRUNLEVEL environment variable.

I can do that if you'll take it then.

> This bug does bring up an interesting question. if we can't determine
> RC_DEFAULTLEVEL in a generic way, should we consider dropping it?

If we drop it then it is hard for a callback indicating system start (added in another patch) to know if it was a boot to the default runlevel or a boot to a runlevel specified on the command line.

I'd really like to keep all existing functionality as it is needed by a project we are working on, hence the bug-fixes and request for enhancement.  :-)
Comment 3 William Hubbs gentoo-dev 2013-05-07 20:36:23 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > 1) Adding a new environment variable named RC_KRUNLEVEL which will contain
> > > the softlevel (or rc_runlevel) kernel command line parameter when supplied.
> > 
> > We have an RC_RUNLEVEL environment variable, so I'm not sure why we need the
> > RC_KRUNLEVEL variable. Does RC_RUNLEVEL have the correct value?
> 
> RC_RUNLEVEL contains the runlevel the script/plugin is currently being run
> from.
> RC_KRUNLEVEL contains the runlevel specified using softinit or rc_runlevel
> on the kernel command line (or is undefined).

I'm not quite sure what you mean by softinit vs rc_runlevel on the kernel command line. If we are talking about softlevel, do we need an environment variable, RC_SOFTLEVEL which would contain the softlevel value?

 > > 2) Replacing hard-coded "default" with a lookup from the inittab file
> > > (falling back to "default" should inittab be unparsable for some reason).
> > 
> > OpenRC is not written to be sysvinit specific, so we should not try to look
> > up runlevels in inittab.
> 
> Hence the fallback to "default" if inittab is unreadable or does not exist. 
> As far as I know there is no other way of knowing the default runlevel.

I just thought of another option for this. How about adding a setting to /etc/rc.conf, and if that setting does not exist we use the hard coded "default"?

It is true that this requires the user to edit rc.conf, but the up side of this approach is it keeps us from having to figure out how to find out the default runlevel in multiple init systems.

> > Also, the patch does not update the runscript man page with documentation
> > about the RC_KRUNLEVEL environment variable.
> 
> I can do that if you'll take it then.

If we still need RC_KRUNLEVEL, pleas do, I'm still not following the purpose of this variable.
Comment 4 Max Hacking 2013-05-08 09:16:55 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > > 1) Adding a new environment variable named RC_KRUNLEVEL which will contain
> > > > the softlevel (or rc_runlevel) kernel command line parameter when supplied.
> > > 
> > > We have an RC_RUNLEVEL environment variable, so I'm not sure why we need the
> > > RC_KRUNLEVEL variable. Does RC_RUNLEVEL have the correct value?
> > 
> > RC_RUNLEVEL contains the runlevel the script/plugin is currently being run
> > from.
> > RC_KRUNLEVEL contains the runlevel specified using softinit or rc_runlevel
> > on the kernel command line (or is undefined).
> 
> I'm not quite sure what you mean by softinit vs rc_runlevel on the kernel
> command line. If we are talking about softlevel, do we need an environment
> variable, RC_SOFTLEVEL which would contain the softlevel value?

Sorry, that was a typo - I meant softlevel.  It seems both parameters (softlevel and rc_runlevel) do the same thing.  I chose RC_KRNULEVEL as the variable name as it is the name of the constant used to look up the value.

We could use RC_SOFTLEVEL if that would be preferred although it would be confusing as there is already another setting (exported via /run/openrc/softlevel which is the same as RC_RUNLEVEL).

Personally I think we should deprecate softlevel as a kernel parameter (and possibly rename the rc_* kernel cmd vars to rc.* to fit with the rest of the kernel while we're at it).

>  > > 2) Replacing hard-coded "default" with a lookup from the inittab file
> > > > (falling back to "default" should inittab be unparsable for some reason).
> > > 
> > > OpenRC is not written to be sysvinit specific, so we should not try to look
> > > up runlevels in inittab.
> > 
> > Hence the fallback to "default" if inittab is unreadable or does not exist. 
> > As far as I know there is no other way of knowing the default runlevel.
> 
> I just thought of another option for this. How about adding a setting to
> /etc/rc.conf, and if that setting does not exist we use the hard coded
> "default"?
> 
> It is true that this requires the user to edit rc.conf, but the up side of
> this approach is it keeps us from having to figure out how to find out the
> default runlevel in multiple init systems.

I can see a support nightmare ensuing if we have two configuration settings which should be the same but could be different.  

The open-rc plugin (and dracut module) we've written aims to reduce support costs by implementing a Last Known Good system similar to that found in another popular OS.  Adding this alternate setting would seem to partially negate the goal of this project.  ;-)

> > > Also, the patch does not update the runscript man page with documentation
> > > about the RC_KRUNLEVEL environment variable.
> > 
> > I can do that if you'll take it then.
> 
> If we still need RC_KRUNLEVEL, pleas do, I'm still not following the purpose
> of this variable.

It's only purpose is that we used to have this information available (through RC_DEFAULTLEVEL) and I didn't want to remove it.  The only way to know if a different runlevel has been selected on the kernel command line is to compare the value of RC_DEFAULTLEVEL and RC_KRUNLEVEL (if it exists).  Feel free to axe it!

On a side note: RC_BOOTLEVEL seems to always contains "boot" and (as far as I can see) it is always the first runlevel entered after sysinit.  Why do we have this variable?  :-)

As long as RC_DEFAULTLEVEL remains, and actually contains the default runlevel, then we're happy and our project can work.