Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 427144 - sys-apps/openrc: allow init scripts to take arguments
Summary: sys-apps/openrc: allow init scripts to take arguments
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 19:24 UTC by William Hubbs
Modified: 2012-07-23 19:27 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Hubbs gentoo-dev 2012-07-18 19:24:08 UTC
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.
Comment 1 Ian Stakenvicius gentoo-dev 2012-07-18 19:47:02 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..
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-07-18 20:02:21 UTC
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.
Comment 3 William Hubbs gentoo-dev 2012-07-18 20:30:58 UTC
(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.
Comment 4 Ian Stakenvicius gentoo-dev 2012-07-19 13:37:54 UTC
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..
Comment 5 William Hubbs gentoo-dev 2012-07-19 14:01:48 UTC
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?
Comment 6 bx 2012-07-23 19:27:35 UTC
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