Professional Web Applications Themes

Confused about connection between an option in rc.conf and the associated action? - FreeBSD

# Redirected from freebsd-newbies to freebsd-questions. # Please do not post technical questions to freebsd-newbies. # This is what freebsd-questions is for. Followups set. On 2005-03-13 02:49, Ola Theander <com> wrote:  The /etc/rc script is the first "rc script" that runs. This is the one that takes care of running all the rest of the rc stuff. In pre-5.X versions of FreeBSD, the /etc/rc script called a predefined set of /etc/rc.* scripts at specific points during the startup process, delegating pieces of the work to them. In 5.3-RELEASE and later versions of FreeBSD, there is a collection of small /etc/rc.d/* ...

  1. #1

    Default Re: Confused about connection between an option in rc.conf and the associated action?

    # Redirected from freebsd-newbies to freebsd-questions.
    # Please do not post technical questions to freebsd-newbies.
    # This is what freebsd-questions is for. Followups set.

    On 2005-03-13 02:49, Ola Theander <com> wrote: 

    The /etc/rc script is the first "rc script" that runs. This is the one
    that takes care of running all the rest of the rc stuff.

    In pre-5.X versions of FreeBSD, the /etc/rc script called a predefined
    set of /etc/rc.* scripts at specific points during the startup process,
    delegating pieces of the work to them.

    In 5.3-RELEASE and later versions of FreeBSD, there is a collection of
    small /etc/rc.d/* scripts, that are called by /etc/rc instead of the
    older /etc/rc.* stuff. The specific order these scripts will have is
    determined at boot time, by the /sbin/rcorder utility.

    Each script, either one of the older /etc/rc.* stuff or the newer
    /etc/rc.d/* scripts, slurps in /etc/rc.conf and then checks what parts
    of the script are enabled to run. It is the responsibility of the
    specific script to check the proper rc.conf variables and act
    accordingly.

    A small example of an rc script that checks a variable and modifies its
    own behavior is /etc/rc.d/tmp, which contains (among other stuff):

    load_rc_config $name

    # If we do not have a writable /tmp, create a memory
    # filesystem for /tmp. If /tmp is a symlink (e.g. to /var/tmp,
    # then it should already be writable).
    #
    case "${tmpmfs}" in
    [Yy][Ee][Ss])
    ...

    Thus, it's not /etc/rc that checks the "tmpfs" variable from rc.conf,
    but the specific script that is interested in its value.

    Regards,

    Giorgos

    Giorgos Guest

  2. #2

    Default RE: Confused about connection between an option in rc.conf and the associated action?

    Hello Giorgos and everybody else

    Thank you for your answers. It clarified things a bit but there is still a
    few things that I don't understand. Say I want to create my own script that
    should run depending on the setting in rc.conf:

    - Do I need to p rc.conf myself in the script or is rc.conf pd once
    and for all by rcorder (or someone else) and the settings are available e.g.
    as environment variables?

    - How is my own script found and executed by the rc script? Does the rc
    script execute all *.sh files in the /etc/rc.d/ directory or is some other
    mechanism used?

    - Must the config string in rc.conf have any correspondence to the actual
    script file using it? E.g. if I add a setting test_enable="YES" my script
    must be named test.sh?

    - This last question is somewhat related to the first. Say that I don't have
    to p rc.conf myself, which variable name to I test in my script for the
    rc.conf setting? E.g. if I have a config string in rc.conf named
    test_enable="YES", how do I test for this variable's value? Do I use
    "test_enable" == "YES" or do I use "test" == "YES", i.e. the "_enable" part
    may be stripped by the pr?

    BTW I use FreeBSD 5.3.

    Kind regards, Ola Theander

    -----Original Message-----
    From: Giorgos Keramidas [mailto:upatras.gr]
    Sent: den 13 mars 2005 03:14
    To: Ola Theander
    Cc: org
    Subject: Re: Confused about connection between an option in rc.conf and the
    associated action?

    # Redirected from freebsd-newbies to freebsd-questions.
    # Please do not post technical questions to freebsd-newbies.
    # This is what freebsd-questions is for. Followups set.

    On 2005-03-13 02:49, Ola Theander <com> wrote: 

    The /etc/rc script is the first "rc script" that runs. This is the one that
    takes care of running all the rest of the rc stuff.

    In pre-5.X versions of FreeBSD, the /etc/rc script called a predefined set
    of /etc/rc.* scripts at specific points during the startup process,
    delegating pieces of the work to them.

    In 5.3-RELEASE and later versions of FreeBSD, there is a collection of small
    /etc/rc.d/* scripts, that are called by /etc/rc instead of the older
    /etc/rc.* stuff. The specific order these scripts will have is determined
    at boot time, by the /sbin/rcorder utility.

    Each script, either one of the older /etc/rc.* stuff or the newer
    /etc/rc.d/* scripts, slurps in /etc/rc.conf and then checks what parts of
    the script are enabled to run. It is the responsibility of the specific
    script to check the proper rc.conf variables and act accordingly.

    A small example of an rc script that checks a variable and modifies its own
    behavior is /etc/rc.d/tmp, which contains (among other stuff):

    load_rc_config $name

    # If we do not have a writable /tmp, create a memory
    # filesystem for /tmp. If /tmp is a symlink (e.g. to /var/tmp,
    # then it should already be writable).
    #
    case "${tmpmfs}" in
    [Yy][Ee][Ss])
    ...

    Thus, it's not /etc/rc that checks the "tmpfs" variable from rc.conf, but
    the specific script that is interested in its value.

    Regards,

    Giorgos


    Ola Guest

  3. #3

    Default Re: Confused about connection between an option in rc.conf and the associated action?

    On 2005-03-13 13:15, Ola Theander <com> wrote: 

    This is done implicitly, by the common code present in ``/etc/rc.subr''. A
    typical rc.d script that uses the rc.subr stuff to do its work will contain
    near the beginning a line like:

    . /etc/rc.subr

    This pulls in a lot of useful shell code. In particular, the load_rc_config()
    and run_rc_command() shell functions are defined after rc.subr has been pulled
    in. These two functions can then be used as an abstraction around the rc.conf
    options, as shown in the final two lines of every /etc/rc.d script:

    load_rc_config "${name}"
    run_rc_command "$1"

    The first of these two lines takes care of finding out which options of
    rc.conf apply for this particular rc.d script and preparing internal
    ``rc.subr'' variables that are used to perform the action requested
    (start, stop, restart the service associated with the rc.d script, etc).
     

    All the *.sh and all the executable files under ``/etc/rc.d'' are considered
    rc scripts and are run by the following part of ``/etc/rc'':

    files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null`

    for _rc_elem in ${files}; do
    run_rc_script ${_rc_elem} ${_boot}
    done

    The logic of the tests and what _is_ an rc script is hidden a bit, in the
    definition of run_rc_script() within ``/etc/rc.subr''.
     

    Not necessarily. The load_rc_config() shell function takes care of setting
    the ``rc.conf'' variables that you ask for. You could call your rc script
    ``/etc/rc.d/ola'' and then set "$name" in the script itself to something
    different:

    % grep name /etc/rc.d/ola
    name='myrc'

    Then ``/etc/rc'' would run as a script called ``ola'' but use myrc_="YES"
    options from the ``/etc/rc.conf'' file.
     

    You don't have to explicitly test anything, unless you really need to
    (i.e. your rc script depends on at least one other option being set).
     

    You don't. At least you don't have to. You just set $name to the proper
    value and let run_rc_command() do the checks for you.

    If you find yourself in the need to _do_ some check though, the checkyesno()
    shell function of ``/etc/rc.subr'' can help a lot:

    if checkyesno "${test_special}" ;then
    # The special ``test_special'' option is set.
    # Do something about it.
    fi
     

    The _enable part *is* necessary, AFAIK.

    Regards,
    Giorgos

    Giorgos Guest

Similar Threads

  1. Replies: 0
    Last Post: June 16th, 02:04 PM
  2. Replies: 0
    Last Post: July 9th, 08:54 AM
  3. Missing Dial-Up option in Connection Wizard
    By Lyle in forum Windows Networking
    Replies: 2
    Last Post: July 2nd, 08:50 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139