Summary: | sys-apps/openrc: allow init scripts to take arguments | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | William Hubbs <williamh> |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | mgorny, ryao |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
William Hubbs
2012-07-18 19:24:08 UTC
..since the 'commands' an init script takes are pre-defined, i would expect openrc could still process multiple commands in one go? ie, script takes 'start stop restart status' (just the defaults) /etc/init.d/script start arg1 arg2 stop arg1 ..should be parseable, shouldn't it? shift through arguments, if $1 is empty or matches $valid_commands, then process request so far; then if $1 is not empty start again.. I believe you are first suggesting a solution, then describing the problem. How would the command-line arguments influence the script state? Would it mean that every script using them would have to multiplex all possible actions and store multiple states? Looking at your uses, I believe you actually want a good way to multiplex the scripts. This is mostly what I mentioned using words like 'templates' (what systemd does for similar case) or 'virtual init.d files'. I believe we should be discussing the possible solutions to a problem rather than one solution treating the problem as minor footnote. (In reply to comment #1) > ..since the 'commands' an init script takes are pre-defined, i would expect > openrc could still process multiple commands in one go? > > ie, script takes 'start stop restart status' (just the defaults) > > /etc/init.d/script start arg1 arg2 stop arg1 > > ..should be parseable, shouldn't it? shift through arguments, if $1 is > empty or matches $valid_commands, then process request so far; then if $1 is > not empty start again.. The bigger problem occurs when you have an argument that is also a command e.g. What happens if you run: /etc/init.d/foobar bas when $valid_commands includes "foobar bas" and foobar takes arguments. To touch a bit further on what mgorny was mentioning, how exactly will arguments be handled if openrc accepts them? Looking at some of the examples provided so far, for (1) and (2) the init scripts would essentially be integrating the argument into the runtime context, IE: /etc/init.d/jail start thisjail ..would not necessarily put 'jail' in started state, but would put 'jail thisjail' in started state. Same would go for 'newnet' with per-interface argument(s). However with 'newnet' one would probably want it 'up' after the first interface, while with 'jail' one would probably want it 'up' after all the jails are. So this functionality would need defining somehow -- would rc_depend_strict be enough for that, in rc.conf ? I believe/assume that it can be set on a per-init-script basis so that strictness can differ, yes? Secondly, will arguments be limited solely to defining separate individual runtime contexts (the way we use symlinks to a single init script now), or will they also be permitted to be used (or used anyways) for other configuration settings that would -not- define a separate context? ie (fictitious example): /etc/init.d/mysql start debug ..would start mysql in 'debug' mode, and although this would affect the state of the daemon itself it would not represent a separate context -- ie, /etc/init.d/mysql would still move to 'started' and would need to be 'stopped' if one wanted to start it in non-debug mode.. I want to address another suggested proposal for how to pass command line arguments to scripts that was brought up on the ml. I will also reply there. It was proposed that we could use a command line option, e.g. --args, to signal when the arguments start and allow only a single command on a command line with arguments. Otherwise we would still allow multiple commands. I don't really like this either because it still has ambiguities. e.g. /etc/init.d/service foo bar bas --args arg1 arg2 1) which command should be run? 2) what do we do with the other commands on this command line? something like /etc/init.d/service cmd0 -- cmd1 arg0 arg1 -- cmd2 -- cmd3 arg0 arg1 arg2 or /etc/init.d/service cmd0 -- cmd1 --arg0 --arg1 cmd2 -- may be reasonable /etc/init.d/network eth0 stop -- eth1 restart -- eth2 start -- eth3 stop for newnet something like /etc/init.d/network eth0 --stop eth1 --restart tun0 --upevent br1 --show As discussed on #openrc, WONTFIX. Not worth it. |