Other rc.subr function usage in rc.d script

Hi,

I have difficulties to understand the syntax to use rc.subr function and arguments.

I would like to use run_rc_command in my rc.d script but how should I call for argument and use this function anyway?
Is it a replacement for start_cmd= or should I do start_cmd=run_rc_command args?
and so should it be something like :
Code:
: $command  = screen -S flood-rtorrent -dm rtorrent
: ${name}_user = flood
start_cmd= run_rc_command $command ${name}_user
?

I don't really have any clue how to interpret the docs about rc.subr
no example in rc.d using rc.subr so.... difficult to have an idea
 
I've looked to all those things. But to me, there are a lot of small details that isn't said explicitly.

Code:
start_precmd="${name}_prestart"5
stop_postcmd="echo Bye-bye"6

extra_commands="reload plugh xyzzy"7

plugh_cmd="mumbled_plugh"8
xyzzy_cmd="echo 'Nothing happens.'"

mumbled_prestart()
{
    if checkyesno mumbled_smart; then9
        rc_flags="-o smart ${rc_flags}"10
    fi
    case "$mumbled_mode" in
    foo)
        rc_flags="-frotz ${rc_flags}"
        ;;
    bar)
        rc_flags="-baz ${rc_flags}"
        ;;
    *)
        warn "Invalid value for mumbled_mode"11
        return 112
        ;;
    esac
    run_rc_command xyzzy13
    return 0
}

mumbled_plugh()14
{
    echo 'A hollow voice says "plugh".'
}
in the example of the handbook, xyzzy and plugh are use as arguments I presume? But the name of the variable is xyzzy_cmd not only xyzzy. So does the rc know that every _something is not in the name of the variable but is the type of the parameter?

Or is it that note from the rc.subr article :
Note: ()rc.subr(8). You should additionally set command_interpreter to let rc.subr(8) know the actual name of the process if $command is a script.
For each rc.d script, there is an optional rc.conf(5) variable that takes precedence over command. Its name is constructed as follows: ${name}_program, where name is the mandatory variable we discussed earlier. E.g., in this case it will be mumbled_program. It is rc.subr(8) that arranges ${name}_program to override command.
Of course, sh(1) will permit you to set ${name}_program from rc.conf(5) or the script itself even if command is unset. In that case, the special properties of ${name}_program are lost, and it becomes an ordinary variable your script can use for its own purposes. However, the sole use of ${name}_program is discouraged because using it together with command became an idiom of rc.d scripting.() manual page" href="https://man.freebsd.org/cgi/man.cgi?query=
Some programs are in fact executable scripts. The system runs such a script by starting its interpreter and passing the name of the script to it as a command-line argument. This is reflected in the list of processes, which can confuse rc.subr(8). You should additionally set command_interpreter to let rc.subr(8) know the actual name of the process if $command is a script.
For each rc.d script, there is an optional rc.conf(5) variable that takes precedence over command. Its name is constructed as follows: ${name}_program, where name is the mandatory variable we discussed earlier. E.g., in this case it will be mumbled_program. It is rc.subr(8) that arranges ${name}_program to override command.
Of course, sh(1) will permit you to set ${name}_program from rc.conf(5) or the script itself even if command is unset. In that case, the special properties of ${name}_program are lost, and it becomes an ordinary variable your script can use for its own purposes. However, the sole use of ${name}_program is discouraged because using it together with command became an idiom of rc.d scripting.&sektion=&manpath=freebsd-release-ports">
Some programs are in fact executable scripts. The system runs such a script by starting its interpreter and passing the name of the script to it as a command-line argument. This is reflected in the list of processes, which can confuse rc.subr(8). You should additionally set command_interpreter to let rc.subr(8) know the actual name of the process if $command is a script.
For each rc.d script, there is an optional rc.conf(5) variable that takes precedence over command. Its name is constructed as follows: ${name}_program, where name is the mandatory variable we discussed earlier. E.g., in this case it will be mumbled_program. It is rc.subr(8) that arranges ${name}_program to override command.
Of course, sh(1) will permit you to set ${name}_program from rc.conf(5) or the script itself even if command is unset. In that case, the special properties of ${name}_program are lost, and it becomes an ordinary variable your script can use for its own purposes. However, the sole use of ${name}_program is discouraged because using it together with command became an idiom of rc.d scripting.()
which actually means : you have the name what you want to use then _ then the kind of things you want to use, if it is an argument or a cmd or paramerters ...

that what isn't clear for me.
plus you have apparently parameters which you need to spell completely and others where you need to give a name to it.

the thing I need to translate is
Bash:
su -m -c 'screen -S flood-rtorrent -dm rtorrent' flood
and
Bash:
su -m -c 'screen -S flood-rtorrent -X quit' flood
.
I don't want necessarely a solution to that, I want to understand what is the hierarchy in all those command or args because it seems that there is no apparent logic to it. I can't even figure it out if the function into rc.d like start_cmd are more elevated than run_rc_command from rc.subr since there are on the same level in the file from syntax point of view.
 
Here is a sample script that might fit your case. It supports screen(1), tmux(1), as well as running interactive program on a free virtual terminal.

Instructions:
  • save attached script as /usr/local/etc/rc.d/torrent, for example,
  • search & replace "runprog" with "torrent",
  • create /etc/rc.conf.d/torrent, /usr/local/etc/rc.conf.d/torrent or add directly to /etc/rc.conf:
Bash:
torrent_enable="YES"
torrent_bin="/usr/local/bin/rtorrent"
torrent_vt=... # see below
torrent_user=... # see below
You'll also have to pick where user interface shall go (torrent_vt=...):
  • ttyv4 for virtual terminal (don't forget to free it in /etc/ttys),
  • tmux for tmux, or
  • screen for screen.
Lastly, decide user you wish to run everything under (running as root would be unwise): torrent_user=foo. Then try
Bash:
# service torrent status
# service torrent start
# service torrent attach
# service torrent detach
If using tmux or screen don't forget to consult respective manages on how to detach from the console.
 

Attachments

  • runprog.txt
    3.9 KB · Views: 294
Back
Top