Currently, OpenRC's init scripts cannot process command line arguments. It has been proposed that we change this, in particular, I see two advantages this would allow: 1) In FreeBSD, their jail init script has the ability to start and stop individual jails by accepting the name of the jail as a command line argument. Right now, the equivalent in OpenRC would be to multiplex the jail script. 2) It would allow newnet to be improved to be able to stop and start individual network interfaces, which would eliminate one of the primary concerns about it. The down side is that we would have to disallow multiple commands for an init script on one envocation, so things like: /etc/init.d/foo command1 command2 ... would not work. I am opening this bug to get some feedback on whether or not we should do this. Any input is appreciated.
..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.
