Re: /usr/local/etc/rc.conf & rcorder

From: Nagilum (freebsd_at_nagilum.org)
Date: 05/30/04

  • Next message: Olivier Houchard: "Re: config/kernel version mismatch after cvsup"
    Date: Sun, 30 May 2004 17:26:07 +0200
    To: Danny Braniss <danny@cs.huji.ac.il>
    
    

    Danny Braniss wrote:

    >>On Sat, 29 May 2004, Patrick Tracanelli wrote:
    >>
    >>
    >>>I remember it has been discussed before, but the terms were a little bit
    >>>different, so tell me, isn't it appropriate rc.subr to suck the
    >>>configuration parameters from /usr/local/etc/rc.conf instead of
    >>>/etc/rc.conf when running startupscripts for third party applications
    >>>(/usr/local/etc/rc.d/)?
    >>>
    >>>To keep the organization principles, I dislike putting those
    >>>instructions into /etc/rc.conf when it should be read by 3rd party apps,
    >>>since I consider /etc/ to be used by the base system. Altho' old style
    >>>.sh scripts are still usefull under ${local_startup} dirs, ports
    >>>maintainers tend to write new style rc scripts that uses rc.subr to read
    >>>the user defined options (usually via /etc/rc.conf).
    >>>
    >>>Easy solution would be
    >>>
    >>>rc_conf_files="/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.conf"
    >>>
    >>>into /etc/rc.conf, but it seems to be ignored by rc.subr when it's not
    >>>at /etc/defaults/rc.conf;
    >>>
    >>>Some 3rd party startupscripts read rc.subr from /usr/local/etc/, so if
    >>>it suck only ${PREFIX}/etc/rc.conf options, would force users to
    >>>configure it in the right place, but it would break POLA and since some
    >>>scripts read /etc/rc.subr instead if ${PREFIX}/etc/rc.subr, would also
    >>>break some ports (very very bad idea).
    >>>
    >>>So, to allow ports startupscript to be configured from
    >>>/usr/local/etc/rc.conf but also prevent people who are today used to mix
    >>>everything in /etc/rc.conf from having their app. not starting, defining
    >>>
    >>>rc_conf_files="/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.conf"
    >>>
    >>>into /etc/defaults/rc.conf would just do it, nothing would break and
    >>>port's pkg-message could start trying to educate users to populate
    >>>/usr/local/etc/rc.conf for ports startup options and leaving
    >>>/etc/rc.conf only for the base system...
    >>>
    >>>
    >>Having multiple locations for system startup parameters (A là Windows) is
    >>a maintenance headache even when there's a logical method to the
    >>madness. I'm saying this as the admin of 6 racks packed with 1U and 2U
    >>machines. Be gentle... ;)
    >>
    >>
    >>
    >
    >and some of us (i hope more than one), have /usr/local shared among many.
    >
    >danny
    >
    >
    >
    >
    Hi,

    I strongly support Patricks original proposal, as for the replies, this
    would not interfere with your usual way of doing things, you could still
    keep your ports startup options in /etc/rc.conf it would make no
    difference. But give (optionally) a better separation of base and
    ports. The settings may or may not be exported throught /usr/local/ to
    other hosts, the decision would be up to the admin as changes to rc.conf
    are (nearly) always made manually.
    However while we're at it I also would like to propose the use of
    rcorder for /usr/local/etc/rc.d/. There are certain ports that use
    number prefixes to try to ensure proper startup order (e.g. mysql-client
    or pkgtools, see the discussion prio the introduction of rcorder for why
    this is suboptimal) however as we already have a working solution for
    this problem it is only matter of using it, the required change would be
    minimal:

    bash-2.05b# diff -Naur bash-2.05b# diff -Naur \
    /usr/src/etc/rc.d/localdaemons /etc/rc.d/localdaemons
    --- /usr/src/etc/rc.d/localdaemons Mon May 5 17:38:41 2003
    +++ localdaemons Sat Nov 1 17:11:57 2003
    @@ -29,7 +29,7 @@
                    fi
                    for dir in ${local_startup}; do
                            if [ -d "${dir}" ]; then
    - for script in ${dir}/*.sh; do
    + for script in `rcorder ${dir}/*.sh 2>/dev/null`; do
                                            slist="${slist}${script_name_sep}${script}"
                                    done

                            fi

    (Replace localdaemons with localpkg for newer system.)
    There are certain ports (such as bacula) that would definatly profit
    from this (e.g. all ports that require mysql/pgsql to be running, while
    beeing started)
     Kind regards,
    Alex.

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  • Next message: Olivier Houchard: "Re: config/kernel version mismatch after cvsup"

    Relevant Pages

    • Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
      ... > change the ports, but this is probably not the right fix. ... startup scripts to /etc/rc.d? ... postgresql starts before your mail system). ...
      (freebsd-current)
    • Python crushing on kinterbasdb connect @ FreeBSD
      ... I found it crashing at startup. ... Problem is in connecting to my Firebird database: ... and latest in ports is 3.1; ...
      (comp.lang.python)
    • 111 and 765th ports problem
      ... after an upgrade, 111 and 765th ports have been opening at startup, i ... get package name, in according to /etc/services sunrpc using 111, but i ... How can i find which packages use this ports, and why they start at boot ...
      (Debian-User)
    • Messenger TCP & UDP ports
      ... several ports opened in LISTEN state for the process msmsgs.exe, ... at startup. ... associated ports. ... The process msmsgs does NOT appear in msconfig, but is is persistent in Task ...
      (microsoft.public.windowsxp.messenger)