Error occurs on eselect rc show: loki ~ # eselect rc show /usr/share/eselect//modules/rc.eselect: line 199: /var/lib/init.d//softlevel: No such file or directory Status of init scripts in runlevel I am not actually sure that this files is provided by baselayout, but since that seems to be the only delta relative to working systems that seemed relevant, I've guessed at who to blame for this. P.S. Happy honeymoon, UberLord. Reproducible: Always Steps to Reproduce:
Our state dir should *never* be referenced by programs other than baselayout - we provide an API for that. Something like this . /etc/init.d/functions.sh # baselayout-1 compat [ -e "${svclib}"/sh/rc-services.sh ] && . "${svclib}"/sh/rc-services.sh service_started foo && einfo "started"
Is there going to be a patched version anytime soon? I can provide a patch if this is aprecoated.
I thought it worked yesterday but today I get the same error message. (In reply to comment #2) > Is there going to be a patched version anytime soon? > > I can provide a patch if this is aprecoated. > yes please do so
Created attachment 163061 [details, diff] /usr/share/eselect/modules/rc.select patch for baselayout 2 This patch should be only applied to systems where baselayout 2 is running, because it just fixed the default RC_SVCDIR. The usage of the API as suggested above is *not* possible with eselect, since /etc/init.d/functions.sh uses "eval", which is prohibited by core.bash. BTW: Where is the f**king documentation of that API?
(In reply to comment #4) > Created an attachment (id=163061) [edit] > /usr/share/eselect/modules/rc.select patch for baselayout 2 > > This patch should be only applied to systems where baselayout 2 is running, > because it just fixed the default RC_SVCDIR. hm, "svcdir" in /etc/conf.d/rc needs to be changed too from /usr/share/eselect/modules/rc.select ------ rc_svcdir() { local ret=$(load_config ${ROOT}/etc/conf.d/rc svcdir) echo ${ret:-${RC_SVCDIR}} }
(In reply to comment #5) > > hm, "svcdir" in /etc/conf.d/rc needs to be changed too > This is no business of eselect. I do not have such variable set there. on my machine using Baselayout 2 there isn't even a /etc/conf.d/rc. If this varable is always set in /etc/conf.d/rc when using baselayout 1, then this patch is crude, but will work for both baselayouts. > from /usr/share/eselect/modules/rc.select > ------ > rc_svcdir() { > local ret=$(load_config ${ROOT}/etc/conf.d/rc svcdir) > echo ${ret:-${RC_SVCDIR}} > } > In fact: I would rather use the API and not mess with the direct path, but since bash.core prohibits the use of eval and functions.sh uses it, we're doomed at the moment.
(In reply to comment #6) > In fact: I would rather use the API and not mess with the direct path, but > since bash.core prohibits the use of eval and functions.sh uses it, we're > doomed at the moment. Not really, since you can unset the function: local evil_eval=$(declare -f eval) unset -f eval ... do some work ... eval "${evil_eval}" A patch using the API (as pointed out by Roy in comment #1) would really be appreciated.
Created attachment 188916 [details, diff] /usr/share/eselect/modules/rc.select patch for baselayout 2 with use of API OK, this is just tested on baselayout 2, since I do not have a baselayout 1 machine, could please someone check this.
(In reply to comment #8) > OK, this is just tested on baselayout 2, since I do not have a baselayout 1 > machine, could please someone check this. Thanks. Looks like we have two problems with baselayout-1: + local runlevel=$(/bin/rc-status -r) rc-status of baselayout-1 has no -r option. + for x in hotplugged started starting stopping stopped inactive crashed; do + service_${x} ${script} && write_kv_list_entry ${script} "[${x}]" baselayout-1 doesn't have service_hotplugged and service_crashed. As far as I know, only the following 5 states are mutually exclusive: "stopped", "started", "stopping", "starting", and "inactive". Questions to Roy (adding to CC): rc-status of OpenRC has also "scheduled". Is this a 6th alternative? What is the reason that there is no "service_scheduled" command?
(In reply to comment #9) > Looks like we have two problems with baselayout-1: > > + local runlevel=$(/bin/rc-status -r) > > rc-status of baselayout-1 has no -r option. baselayout-1 has no means of returning the currently runlevel beyond parsing the full rc-status output or by looking directly at the state data. > > + for x in hotplugged started starting stopping stopped inactive crashed; do > + service_${x} ${script} && write_kv_list_entry ${script} "[${x}]" > > baselayout-1 doesn't have service_hotplugged and service_crashed. > As far as I know, only the following 5 states are mutually exclusive: > "stopped", "started", "stopping", "starting", and "inactive". Correct > Questions to Roy (adding to CC): rc-status of OpenRC has also "scheduled". > Is this a 6th alternative? What is the reason that there is no > "service_scheduled" command? No, a stopped service can be scheduled to be started when another service starts. It's status is both stopped and scheduled. I didn't see a reason to add a service_scheduled command. If there is a need to add it, then there should also be a services_scheduled command, like so # service_scheduled a foo bar # services_scheduled foo a If you feel a need for this, please file a request at http://roy.marples.name/projects/openrc/newticket
(In reply to comment #10) > > rc-status of baselayout-1 has no -r option. > > baselayout-1 has no means of returning the currently runlevel beyond parsing > the full rc-status output or by looking directly at the state data. So I guess we have to do something like the following. Really ugly. get_runlevel() { if type rc_runlevel &>/dev/null; then rc_runlevel else # baselayout-1 doesn't have rc_runlevel() local svcdir=$(load_config /etc/conf.d/rc svcdir) cat "${svcdir:-/var/lib/init.d}/softlevel" fi }
(In reply to comment #11) > else > # baselayout-1 doesn't have rc_runlevel() > local svcdir=$(load_config /etc/conf.d/rc svcdir) > cat "${svcdir:-/var/lib/init.d}/softlevel" I just see that functions.sh of baselayout-1 exports the SOFTLEVEL variable, so probably this could be used in the "else" part.
Created attachment 188953 [details, diff] /usr/share/eselect/modules/rc.select patch with use of API I change the patch according the annotations. I just removed crashed and hotplugged states and change the runlevel detection in the show function. The detection of the current runlevel is only used in the show action, so I did not see the need for a function for the whole module and it need in fact the functions.sh to work proper. And because of the eval statement, I did not want to include it in the whole module.
> I change the patch according the annotations. I just removed crashed and > hotplugged states and change the runlevel detection in the show function. Thank you again. Tested with OpenRC and baselayout-1 and works with both. > The detection of the current runlevel is only used in the show action, so I > did not see the need for a function for the whole module and it need in fact > the functions.sh to work proper. I think it's cleaner to move such things to their own function, but it's a matter of taste of course. ;-) Committed to SVN (r476). I've also moved the sourcing of functions.sh into a subshell (and we don't have to restore "eval" then), and added some colours for the different states. You may emerge app-admin/eselect-9999 for testing, or get the rc module from here: <http://sources.gentoo.org/viewcvs.py/eselect/trunk/modules/rc.eselect?view=markup>
(In reply to comment #14) > > I change the patch according the annotations. I just removed crashed and > > hotplugged states and change the runlevel detection in the show function. > > Thank you again. Tested with OpenRC and baselayout-1 and works with both. > > > The detection of the current runlevel is only used in the show action, so I > > did not see the need for a function for the whole module and it need in fact > > the functions.sh to work proper. > > I think it's cleaner to move such things to their own function, but it's a > matter of taste of course. ;-) You should then make a comment that the $SOFTLEVEL is only defined if you call source_rc_functions before get_runlevel. Or later someone will change the ordering and keeps on wondering why it does not work anymore... > > Committed to SVN (r476). I've also moved the sourcing of functions.sh into a > subshell (and we don't have to restore "eval" then), and added some colours for > the different states. >
> You should then make a comment that the $SOFTLEVEL is only defined if you > call source_rc_functions before get_runlevel. Done.
Fixed in eselect-1.1_rc1.
