Other rc.subr function usage in rc.d script

boistordu

New Member


Messages: 12

#1
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
 
OP
OP
B

boistordu

New Member


Messages: 12

#3
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://www.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.
 

Bobi B.

Active Member

Thanks: 86
Messages: 200

#4
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

Top